デザインパターン再考

　各人でバイブルと呼んでもいいぐらい影響を受けた本、そして愛用している本はあると思うが、自分にはGoFの「オブジェクト指向における再利用のためのデザインパターン」が相当するように思う。

　仕事で手が空いている時は、この本のCD-ROMに付属していた抜粋HTMLをよく読んでいるからだろう。

　デザインパターンとは、「より良いインターフェイス設計手法」と呼ぶことも出来る。
　23個のパターンは、粒度の違いはあれど、いずれも珠玉の概念だ。
　
　そもそもデザインパターンに惹かれるのは何故だろう？
　それは、似たようなインターフェイス設計を何度も行った経験があるから。
　詳細設計やプログラミングでデジャブをいつも感じるから。
　リファクタリングと絡めると理解しやすい。

　23個のデザインパターンは、個人的には「ポリモルフィズム」「仲介コントローラ」「インスタンス管理」の3種類で分類できると考える。

１．殆どのパターンはポリモルフィズムの原理を使っている。

　ポリモルフィズムの意義は条件分岐の除去だ。
　実際には、複雑なIF文を呼び出し側から呼ぶ側へ移動することにある。この手法を徹底すると、複雑な条件分岐のアルゴリズムがModelからViewへ移るため、最終的にはリフレクションで条件分岐を全て除去できる。

　具体的には、ポリモルフィズムの対象オブジェクトは、アルゴリズム(Strategy)、状態(State)、要求(Commnad)、再帰(Composite)、コンテナ(Iterator)、文法処理(Interpreter)によって観点が異なるだけ。

　2個のパターンを組み合わせたパターンもある。
　DecoratorはCompositeとStrategyを組み合わせたパターンだし、Chain of ResponsibilityはDecoratorにイベントの概念を追加したパターンと言える。

　特異なパターンがVisitorだ。
　以前は「Visitorパターンはどこで使うのだろう？」と疑問に思っていたが、一言で言えば「マトリックス型のポリモルフィズム」。
　つまり、Visitorクラスはswitch文をクラス化したものとして、その構造が自然に現れる。

２．仲介コントローラを導入するパターンは、複雑な処理を委譲する原理を使う。
　仲介コントローラを導入する意義は、処理の複雑さを凝集度の観点から、一つへまとめたり2個以上へ分割することだ。

　仲介コントローラの対象オブジェクトの役割が、インターフェイス適合(Adapter)、処理の仲介(Proxy)、Controllerの共通インターフェイス(Facade)、オブジェクト間の複雑な通信制御を一つにまとめるもの(Mediator)などと観点が異なる。
　
　最も奥が深いのは、Observerパターンだ。Observerパターンはイベントの概念そのものだが、Multicastパターンで実装されることが多い。
　JavaとC#ではプログラミングスタイルが大きく異なる部分でもある。

３．インスタンス管理を導入するパターンは、用途によって異なる。

　ポリモルフィズムと組み合わせ（AbstractFactory）、コンストラクタ置換(FactoryMethod)、唯一のインスタンス生成(Singleton)、インスタンス複製(Prototype)、インスタンスの履歴保持(Memento)などがある。

　デザインパターンは、実装言語によって大きく異なる部分がある。
　Java、C#、VB、Rubyなどで書いてみると、実装言語の制約でデザインパターンを使えない時があったり、デザインパターンそのものの実装が長くなったりする。
　実装言語の比較によって、自分なりのデザインパターンの解釈を今後、連載してみたいと思う。