エキスパートPythonプログラミング読書会に参加してきました
この日は14章「Pythonのためのデザインパターン」。一度は行ってみたいと思っていたのと、デザインパターンに興味があったので参加してみました。
以下気になったところのメモ。
- Singletonパターン
- 概念としては押さえておくべきだけど、結局グローバル変数なので使い過ぎるのもどうなのよ、という議論があるらしい
- 本にも書いてあるようにモジュールを使ったほうがよい
- モジュール内で名前の前にアンダーバーを付けて隠蔽してやる
- 最後にdelしておく(参照カウント等との兼ね合いから)
- Adapterパターン
- その名のとおり「変換アダプター」
- 本の例だと、文字列をStringIOでラップしてやることで、あたかもファイルであるかのように扱えるようにしてやる
- Interface
- proxyパターン
- 本のurllibの例はproxyパターンとは言わない
- インターフェイスを変えず、メソッドに付加的な価値をつけてやるのがproxy
- 通常は読み込むだけだったものをキャッシュも効くようにしてやる、とか。
- facadeパターン
- SimpleHTTPServerの例
- ここでサーバが死なないというアクシデント発生
- それはさておき、Facadeとは例えばスターターキットみたいにひと通りの機能をまとめたオールインワンパッケージも提供するし、お望みならば自分で一から組み立てることもできるよっていうパターン
- observerパターン
- 監視役という名前に半して監視対象から教えてもらう。名前に騙されてはいけない
- visitorパターン
- データの構造の変化ではなく種類が増えるとどちらも変更しなくてはならない。
- 構造が変わっただけならいじらなくてよい
- Template Methodパターン
- ベースクラスでテンプレートとして最低限の実装をしておいて、具体的な実装をサブクラスでオーバーライドして使う
- 全体的にサンプルコードがあまり良くないという話が。
- デザインパターンを概念として押さえておくことに損はない
- ただし実際の実装でデザインパターンにとらわれすぎて実装が残念な感じになっては本末転倒
- パターン厨になってはいけない
- ていうか今コレ(デザインパターン)使う?
- ↑はすでに言語に用意されてたりとかで、実際に自分で作ることはない、みたいな話だったと思う。
- それっぽい名前が付いてるので名前から大体の実装を予測することができるっていう意味でも概念を押さえておいたほうがいいっぽい。
- 「そういえば(この本)Strategyパターンが出てこなかったね」みたいな話もあった。
- F#読書会で、関数型言語で使わなくなったパターンとしてStrategyが出てきたような記憶があるのでこれは興味深い。*1
こんな感じだったかなぁ。
そういえばF#読書会でもデザインパターンの話が出てきたし、そこで「名古屋scalaでデザインパターンについての議論がある」とかなんとか言ってた気がするので、これは押さえておいたほうがよさげ。何よりもこの章を通じて、自分のコーディング力がまだまだだなと思ったので。学ばなきゃならないことは山積みですね。
上記の名古屋scala云々はこんな感じだったようです↓
⇒関数型言語であることで勝手に出来上がる/不要になるデザインパターンって何があるの?
⇒StrategyとかCommandとか…
#99 第1回東京F#読書会を開催しました « 勉強会 « F# « Gab_kmのブログ
*1:コメントで教えていただいたのですが、関数もファーストクラスオブジェクトとして扱えるPythonではあまり存在意義を感じないパターンだそうです。関数型言語も同様に関数がファーストクラスオブジェクトなので、両者ともに同じ理由であまり使わないみたいです