Strategy パターン

Strategy パターン（ストラテジー - ）は、コンピュータープログラミングの領域において、アルゴリズムを実行時に選択することができるデザインパターンである。

Strategyパターンはアルゴリズムを記述するサブルーチンへの参照をデータ構造の内部に保持する。このパターンの実現には、関数ポインタや関数オブジェクト、デリゲートのほか、オーソドックスなオブジェクト指向言語におけるポリモーフィズムと委譲、あるいはリフレクションによる動的ダック・タイピングなどが利用される。

このパターンは、関数が第一級オブジェクトである言語では暗黙のうちに使用されている。例として後述のPythonコード例を参照のこと。

Strategy パターンは、アプリケーションで使用されるアルゴリズムを動的に切り替える必要がある際に有用である。Strategy パターンはアルゴリズムのセットを定義する方法を提供し、これらを交換可能にすることを目的としている。Strategy パターンにより、アルゴリズムを使用者から独立したまま様々に変化させることができるようになる。

Strategy パターンを示す図

サンプルコード

Java

Javaではクラスのメソッドオーバーライドによるポリモーフィズムを使ってStrategyパターンを実現することができる。インターフェイスを用いた例を示す。

Python

Python では関数が第一級オブジェクトであり、このパターンを明示的に定義する必要はない。下記はコールバック関数を用いる GUI プログラミングで見られる例である。

C#

C#はJava同様にクラスやインターフェイスによるポリモーフィズムを用いることもできるが、カスタマイズポイントがひとつのメソッドしかない場合（オブジェクトの他のプロパティやメソッドにアクセスしない場合）は、継承関係を必要としないデリゲートを使うほうが好まれる。

なお、Javaもバージョン8以降であれば、メソッド参照と関数型インターフェイス (functional interface) を用いることで、C#と類似の実装が可能となる。

Strategy パターンと開放/閉鎖原則

Strategy パターンに従うと、クラスの振る舞いは継承されるべきではなく、インターフェイスを用いてカプセル化するべきである。例として Car クラスを考えると、Car の振る舞いにはブレーキとアクセルがある。

アクセルとブレーキの振る舞いは車種により異なる場合があるため、良くあるやり方はこれらの振る舞いをCarのサブクラスとして実装することである。が、このやり方には大きな問題点がある。それはアクセルとブレーキの振る舞いが車種間で同じでも、車種ごとに新たに宣言・定義し直されなければならない事である。これは車種が少ないときには小さな問題で済むが、車種が増えるにつれ、それらの振る舞いを管理する作業とコード重複量が大幅に増えてしまうことになる。さらに、各コードを詳しく分析しなければ各車種の振る舞いの性質を知ることができない。

これに対して Strategy パターンでは、継承ではなく合成 (composition) を用いる。Strategy パターンにおける振る舞いは別々のインターフェイスと、これらのインターフェイスを実装した抽象クラスとして定義される。具体的なクラスは、これらのインターフェイスをカプセル化する。これにより、振る舞いと、それを用いるクラスがうまく分離できる。振る舞いは、それを用いるクラスに変更を加えずに変更することができ、クラスは大きなコード変更を必要とすることなく、使用する実装を切り替えることで振る舞いを切り替えることができる。振る舞いは設計時にも実行時にも変更することができる。例として、Car オブジェクトのブレーキの振る舞いを、メンバー brakeBehavior を BrakeWithABS から Brake に変えることで変更できる：