Strategyパターン
Head First デザインパターンのメモ。
Strategyパターン
一連のアルゴリズムを定義してそれぞれをカプセル化し、それらを交換可能にする。
Strategyパターンによって、アルゴリズムを使用するクライアントとは独立して、アルゴリズムを変更できる。
設計時の問題点
振舞いがサブクラスごとに変化するため、継承ですべてのサブクラスに振舞いを持たせることが困難な場合がある。
インターフェースで実装しても、コードが再利用できず保守が難しい。
継承のデメリット
- コードがサブクラス間で重複することがある
- 実行時の振舞いを変更することが困難
- 全てのサブクラスの振舞いを把握することが困難
- 変更によって他のクラスに影響を与える可能性がある
解決方法
変化する部分を取り出し、それをカプセル化する。
他に影響を与えず、変化する部分を拡張できる。
振舞いを設計する
それぞれの振舞いを表すインターフェースを実装し、振舞いを表すことだけを目的としたクラス群を作成する。
それを使うサブクラスが実装の詳細を知る必要がなくなる。
振舞いの統合
鴨を表すDuckクラスに、鳴く振舞いを表すQuackBehaviorの機能を委譲する場合。
public class Duck { // QuackBehaviorインターフェースを実装したクラスへの参照 QuackBehavior quackBehavior; public void performQuack() { // 振舞いをオブジェクトに委譲 quackBehavior.quack(); } }
2つのクラスを統合する際は、コンポジション(composition)を使用する。
継承する代わりに、振舞いオブジェクトで構成(compose)されることで、振舞いを取得する。
