デザインパターン

http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)

コンピュータのプログラミング、素人と達人の間ではびっくりするほどの生産性の差がある

その差はかなりの部分が経験

達人たちが同じ問題に取り組んだ場合、典型的にはみな同じパターンの解決策にたどり着く

これがデザインパターンである (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「責任の鎖」パターン