/note/tech

デザインパターンを読み解く

GoFの23パターンをそのまま解説している本が多く、事細かな制約があるかのように見えるせいか、かえって本質が捉えづらくなっている印象があります。23パターンがすべてではないし、このパターン自体パターンが言われ始めた初期に出されたもので、洗練されていないと思うのです。「○○パターン」と言われると何か特殊なテクニックなのだと考えてしまい、かえって難しくとらえているのではないでしょうか。

正直言って、クラス設計の上位レベルのコンセプトと、コーディングのテクニックをごっちゃにしたような印象があります。

よく、デザインパターンをそのまま適用できないという意見がありますが、それもそのはずで、挙げられているのはクラス構成における一例にすぎません。無理に当てはめて、「このアプリケーションには○○のデザインパターンが使われている」などと自慢するのは意味がないし、細かく分析して「StrategyとStateの違いはこうである」などと研究対象にするのも意味がないと思います。GoFの例に合致していないから効果が薄いと思うのも間違いです。

最初にデザインパターンを知った時は理解できないパターンも多くて、自分のスキルが低いせいかな? と思ってた時もあったものだが、今改めて見ても「いや、これは使い道ないだろ」みたいなのはやっぱりある。

というか、元々Javaの古いバージョンでGUIアプリを作成することを想定している感じから、主にWEBアプリ(API)では使う場面がないパターンが出てくるのは当然ではある(FlyWeightとかChainOfResponsibilityとか)。

そういう観点で改めてデザインパターンの再評価をするのも面白いかもしれない。