コンピュータのプログラミング、素人と達人の間ではびっくりするほどの生産性の差がある
その差はかなりの部分が経験
達人たちが同じ問題に取り組んだ場合、典型的にはみな同じパターンの解決策にたどり着く
これがデザインパターンである (GoF)
GoF:
エーリヒ・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシディースの4人
書籍『オブジェクト指向における再利用のためのデザインパターン』
最善の解決策ではないかもしれないが、
その種の問題に対するトレードオフも考慮した、典型的な解決策
23種類のパターン
デザインパターンはすべての状況における最善の設計では決してない。
デザインパターンをむやみに適用するのは不適切
不適切な使用はコードの複雑さを無意味に高めてしまう
デザインパターンはよく使われる設計を抽出して一般化したもの
あくまでも設計のコンセプトとして参照
http://www.techscore.com/tech/DesignPattern/index.html/
http://thinkit.co.jp/book/2009/04/30/565
効率的な生産性、再利用や修正などのメンテナンス性を考えると、
本来のオブジェクト指向らしいプログラミングをすべき
GoF(the Gang of Four)のデザインパターン
・生成に関するパターン
Factory Methodパターン
・構造に関するパターン
Adapterパターン
Bridgeパターン
・ふるまいに関するパターン
Chain Of Responsibilityパターン
「サンプルコードで動作を理解→UMLで構造を把握」がコツ!
クラスの構造や各クラスの関連などをひとつひとつコードを入力し、
実行して、そのパターンのふるまいを理解していくことが早道
デザインパターンはUMLでイメージを定着させる
FactoryMethodパターン<生成物を間違わないように>
1.オブジェクトの生成はサブクラスに委ねる
2.間違ったインスタンスが作成することがないようにできる。
サブクラスにインスタンスを委ねるのがポイント
Adapterパターン <間にはさんでかみ合わせ>
Bridgeパターン <機能と実装は分ける>
階層が深くなるほどメンテナンス性は落ちる
比較的利用価値の高いChain of Responsibility「責任の鎖」パターン