Strategy パターンは、コンピュータープログラミングの領域において、アルゴリズムを実行時に選択することができるデザインパターンである。ポリモーフィズムを持たないようなプログラミング言語では、このパターンによって解決される問題は、関数ポインタや委譲を使った記述によりリフレクションの形態で扱われる。このパターンは、関数が第一級オブジェクトである言語では暗黙のうちに使用されている。例として Python コード を参照のこと。Strategy パターンは、アプリケーションで使用されるアルゴリズムを動的に切り替える必要がある際に有用である。Strategy パターンはアルゴリズムのセットを定義する方法を提供し、これらを交換可能にすることを目的としている。Strategy パターンより、アルゴリズムを使用者から独立したまま様々に変化させることができるようになる。Python では関数が第一級オブジェクトであり、このパターンを明示的に定義する必要はない。下記はコールバック関数を用いる GUI プログラミングで見られる例である。Strategy パターンの UML クラス図は Bridge パターンのものと同じである。しかし、これら二つのデザインパターンはその"意図"が同じではない。Strategy パターンは "振る舞い" に対するパターンであるが、Bridge パターンは "構造" に対するパターンである。一般にコンテキストと戦略との結合は、Bridge パターンにおける抽象化と実装の結合より強固である。Strategy パターンに従うと、クラスの振る舞いは継承されるべきではなく、インターフェイスを用いてカプセル化するべきである。例として Car クラスを考えると、Car の振る舞いにはブレーキとアクセルがある。アクセルとブレーキの振る舞いはモデルにより大きく異なるため、良くあるアプローチはこれらの振る舞いをサブクラスとして実装することであるが、このアプローチには大きな問題点がある。すなわち、アクセルとブレーキの振る舞いは、新たな Car モデルごとに宣言されなければならない。これはモデルが少ないときには問題にならないが、モデルの数が増えるにつれ、それらの振る舞いを管理する作業が大幅に増加し、またコードがモデル間で重複することになる。さらに、各コードを詳しく分析しなければそれぞれのモデル用の振る舞いの性質を知ることができない。これに対して Strategy パターンでは、継承ではなく合成を用いる。Strategy パターンにおける振る舞いは別々のインターフェイスと、これらのインターフェイスを実装した抽象クラスとして定義される。具体的なクラスは、これらのインターフェイスをカプセル化する。これにより、振る舞いと、それを用いるクラスがうまく分離できる。振る舞いは、それを用いるクラスに変更を加えずに変更することができ、クラスは大きなコード変更を必要とすることなく、使用する実装を切り替えることで振る舞いを切り替えることができる。振る舞いは設計時にも実行時にも変更することができる。例として、Car オブジェクトのブレーキの振る舞いを、メンバー brakeBehavior を BrakeWithABS から Brake に変えることで変更できる：brakeBehavior = new Brake(); これにより設計に優れた柔軟性をもたせることができ、かつ拡張に対して開放的であり変更に対して閉鎖的であるべきとする OCP (Open Closed Principle, 開放/閉鎖原則)とも調和を保つことができる。

出典:wikipedia