デザインパターン

http://blog.xole.net/article.php?id=525を読んで、前からパターンについて思っていることを絡めてつらつらと。。。

多くの書籍で紹介されているパターンはあくまでGoFの23個だけです。実際にはハタさんの書いてあるとおり「デザパタ本には載らないデザパタ」自体はかなりの数があると思います。というより、「○○パターン」と名前が付いていない属人的なテクニックの方が多いんじゃないでしょうかね。

＃こういう本はあったら面白いかも知れません :-)

で、「なぜGoFか」ということについては、関連する情報が多いとか、エライ人らがまとめたものだからとか、GoFはウケが良いからとか色々理由はあると思いますが、やっぱり他のパターンの基底となるものが多いからじゃないでしょうかね。

＃やっぱり、基本大事

ここからつらつらと。。。

個人的にデザインパターンを扱っていて強く思ったのが、インターフェースの使い方（適用箇所）とか各パーツの役割（責務）とか情報のカプセル化といった、オブジェクト思考的な考え方・見方ができるようになるための「良い教材」である、ということです。

ただし、教科書的に「○○パターンはこういう構造でこういう場面に使う」といったものを覚えても、（極論すると）あまり意味はないと考えています。どちらかというと、「なぜ、この構造になっているのか」を掘り下げて各パターンをみた方が、GoF以外のパターンを見たときにピンと来るものがあるはず、と思っています。

たとえば、Hook OperationパターンもNull Objectパターンもインターフェースをうまく使っていて、実装を簡単に切り替えられるようになっています。で、Processクラスのコンストラクタの引数をHook型オブジェクトにしているところがポイントと思います。こうすれば、Hookインターフェースを継承したクラスのインスタンスであれば、beforeメソッド・afterメソッドを実装していることが「保証される」ことになりますので。DIやAOPの基本的な仕組みも、これを究極に推し進めた結果なんだと思います。

ちょっと話がずれますが、アプリケーションで「○○することを保証する」というのは結構大変です。「データの整合性」もそうですし、PHP4のようなオブジェクトの型を限定しにくい言語の場合もそうです。さもないと、思わぬ不具合に手間取ってしまうことになります。逆に、「保証され」ていると、それに関する事項を意識する必要がなくなる、つまり、開発者の余計な負担が下がり本来注力すべき事項に集中することができるハズです。

話は戻って、「ンな事、当然じゃん！」と思われる方は、すでにそういう考え方や視点が身に付いている人なんだと思います。ただ、皆がそうじゃない（環境によっては、そういう方ばかりかも知れません）ので、エントリレベルを扱う情報なり書籍はまずなくならないし、必要だし、重要だと考えています。この辺は、module.jpのエントリとか前に書いたエントリを見てもらえればと思います。

なので、エントリレベルの情報・書籍は、最初の一歩を踏み出せる「きっかけ」だったり、次のステップのための踏み台だったり、充分存在意義はあると思います。今はちょっとでもググればいくらでも情報が得られる時代なので、必要と感じられれば、自分のレベルに合わせたものを購入すれば良いんじゃないですかね。

あまりまとまってませんが、こんなところで。