デザインパターン

コーディングの品質を高めるように、オブジェクト指向の理解を助けるように、周に２、３回程度のデザインパターンシリーズの勉強会を開催する。肝要内容をこのドキュメントに記録する

デザイン原則

  1. 変化の部分を抽出して独立する
  2. 実装でプログラミングをしなくてインタフェース(SuperType)に対してプログラミングをする
  3. 複合を多く使う、継承を少なく使う
  4. お互い呼び出すクラスらの間で、できるだけ疎結合に設計するように
  5. クラスが、拡張に対してオーブン、修正に対してクローズ(オーブン・クローズ原則)

  6. 依存関係逆転原則：抽象に依存する、実装の詳細に依存しない。

  7. 上位のモジュールは、下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。

  8. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。

パターン

  • Strategyパターン＜戦略・策略＞
  • アルゴリズム(算法)らを定義し、別々でクラス化にする
  • 戦略の切り替えや追加が簡単に行えるようになる
  • アルゴリズムの変更がアルゴリズムらを使うクラスと関係がなし

戦略の部分を抽出して別クラスとして作成しておき、戦略を変更したい場合には、利用する戦略クラスを変更するという方法で対応する。Strategy パターンを利用することで、メソッドの中に溶け込んだ形のアルゴリズムより柔軟でメンテナンスしやすい設計となる

  • Observer パターン＜観察者＞ オブジェクトのインスタンスの間で、一対多の仕組みを定義して、一つインスタンスの状態が変化した際に、そのインスタンス自身が、「観察者」に状態の変化を「通知」する

  • Decoratorパターン＜装飾者＞ 飾り枠と中身を同一視することで、より柔軟な機能拡張方法を提供する機能を一つひとつかぶせていくイメージになります。ある機能を持ったDecorationをコアとなるものにかぶせていくイメージです。
    モカとWhipと付けるDarkRoastカフェを必要なら、

  • FactoryMethod パターン オブジェクトの生成方法に一工夫加えることで、より柔軟にオブジェクトを生成することを目的とするものです。 FactoryMethod パターンでは、インスタンスの生成をサブクラスに行わせることで、より柔軟に生成するインスタンスを選択することが可能となります