オブジェクト指向のこころ・9章・練習問題

Strategyパターンについて書かれた章です。

基礎

  • 新たな要求を取り扱う方法として、どのような方法があるでしょうか?
    • 変更のことを考慮して設計するアプローチを行う。
    • 時とともにシステムがどのように変化していくのかを考える。
    • 変更は将来必ず起こるものであるという前提に立ち、どこに変更が発生するのかを予測する。
  • GoFが提案した、変更に取り組む際の基本原則を3つ挙げてください。
    • 1.実装を用いてプログラミングするのではなく、インタフェースを用いてプログラミングしてください
    • 2.クラス継承よりもオブジェクトの「集約」を多用してください
    • 3.あなたの設計において、何を流動的要素とするべきかを考察してください。設計変更を強いる可能性のあるものが何かを考えるのではなく、再設計せず何を変更可能とするのかを考えるのです。着目すべきは、流動的概念のカプセル化です。
  • Strategyパターンの目的とは何でしょうか?
    • さまざまな業務上の規則(ビジネスルール)やアルゴリズムを、それが発生するコンテキストに応じて使い分けられるようにする。
  • Strategyパターンの因果関係とは何でしょうか?
    • Strategyパターンは、アルゴリズムのファミリを定義するものである。
    • switchおよび/あるいは条件分岐を無くすことができる。
    • すべてのアルゴリズムは、同じ方法で起動しなければならない。(すべて同じインタフェースとなっている必要がある。ConcreteStrategyNとContextのやり取りに際して、Contextの状態を取得するメソッドが必要となることもある。)

応用

  • GoFは「設計において、何を流動的要素とするべきかを考察する」ことを示唆しています。このことと再設計の原因に着目することとは、どのように違っているのでしょうか?
    • 変更に備えた設計を行う方(GoFが示唆している内容)が、変更のことを気に掛けない設計(再設計を引き起こす)を行うよりもコストが掛かるというもの。これはGoFの示唆している方法でのコードが、可読性、テスト可能性、保守容易性に優れた、品質の高いものとなるため。正しいアプローチを実践するために費やした時間の方が、結果的に短くなる。
  • コピー&ペーストにおける問題とは何でしょうか?
    • オブジェクトの再利用を全く考えていない方法である。Strategyパターンはコンテキストに応じて使い分けられるようにする因果関係をもつが、コピー&ペーストによる方法はすでに動作するコードをコンテキストに応じて書き直しているだけである。(と私は思う;前者の方が視点のレベルが高い)
  • 「switchの泥沼」とは何でしょうか?
    • 既存のコードがswitch(もしくはif)によって書かれている場合、新たな条件の発生によって、その条件に関係しそうな部分を探しまわることになる。(たった1箇所の修正であっても、しばしばコード全体を読む羽目になる);条件によって、処理(機能)を分割したはずなのに、これでは本末転倒だ!