GRASPパターン - Variation Protectedパターン(バリエーション防御パターン)

Advertisement

Variation Protectedパターンで提唱するもの

Variation Protectedパターンでは、将来増加されると予測されるバリエーションに対して既存の設計を防御するよう、責務を配置する。

考察

オブジェクト指向での重要なポイントである、「インタフェースに対してプログラミングする。」という指針をパターンとして提唱したもの。

このパターンを知らない場合でも、オブジェクト指向で設計を行っていれば自然に身につくであろうパターンだと思う。

Don't Talk to Strangers(知らないヤツには話し掛けない)

Variation Protectedパターンを実現するために有効な考え方として、Don't Talk to Strangersというものがある。別名をデメテルの法則(the Low of Demeter)といい、メッセージの送信範囲を限定する。その指針は「直接依存するオブジェクトに対してのみ、通信を行う。」というものである。直接依存するオブジェクトは次の通り。
※便宜上、自オブジェクトのことを「自分自身」と記述する。
  • オブジェクト自身
  • 自分自身が属性として保持しているインスタンス
  • 自分自身へパラメータとして渡されたオブジェクト
  • 自分自身のメソッド内で生成したオブジェクト
上記のオブジェクト以外との通信を直接行わないことで、オブジェクト同士の無駄な依存関係を排除することが出来る。

メリット

  • バリエーションが増加した際に、既存のクラスを変更する必要がない。

ものすごく単純な例

例:テキストエディタを作成する。当初扱えるファイル形式はTXT形式とCSV形式だが、今後ファイルの種類が追加になる可能性がある。


悪い例
図1:インタフェースを使用してバリエーションを防御

この例ではインタフェースで不変なメソッドを定義しているため、今後ファイルが増加した際でもインタフェースに準じたクラスを作成すれば、既存のクラスを変更する必要がない。インタフェースを使用してバリエーションを防御する形になる。

×
良い例
図2:ファイルクラスはバリエーションの増加に対して影響を受ける

極端な例だが、ファイルクラスにすべての種類のファイルに対する責務が集中するため、ファイルの種類が追加になると、ファイルクラスを修正しなければならない。

Advertisement

ショートカット

634トップページ
このカテゴリのトップページに戻る
634ラボ

サイト検索

Google

Web サイト内

Y!ログール