デザインパターンを使うよ、どこまでも。

今日の話をする前に、「デザインパターンって何？」って話から始めます（あんまり興味の無い方にはゴメンなさい）。
「オブジェクト指向における再利用のためのデザインパターン」を著したGoF(Gang of Four)の文書をちょっと引用しました。

Design patterns solve specific design problems and make object-oriented desings more flexiblem elegant， and ultimately reusable. They help designers reuse successful designs by basing new designs on prior experience. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.

要は、「オブジェクト指向プログラミングにおいてさー、開発者は大抵同じ問題に直面するのだよ、きっと。いや、絶対。でもさ、結局皆同じパターンの解決策にたどり着くじゃん？だったらそれを予め纏めておいたら便利だよね」という事になります。

コード解析が簡単に済んだのは、以前少し勉強していたGoFのデザインパターンを知っていた事にありました。もう少し優秀なプログラマさんはきっとデザインパターンに対して一過言あることでしょう。
例えば、Factory Method パターンの場合、あまり関連のないクラスをFactory Methodの中でnewするようにしてしまうと、「なんでそんなFactory Methodを呼ばなければならないんだよ（怒）」と思考停止になり、使い方を間違えたり、解り難いコードを書いてしまう可能性が高くなるでしょう。
しかし、デザインパターンはあるプログラムのフレームが想像できると言う点で「共通言語」にもなるのです。
各デザインパターンを組み合わせて使い、そして各パターンの弱点を良く知った上で使えば、かなりいいプログラムになるのかな？と不勉強ながら実感したのでした。

【今日の勉強】
デザインパターンは万能ではない。その効能と弱点を知り、利点を最大限に活かせる様に留意すべき。