戦略パターンとPHP実装

戦略パターン:
戦略パターン: 一連のアルゴリズムを定義し、各アルゴリズムをカプセル化して、それらを交換可能にします。戦略モードでは、ポリシー モード (Policy) とも呼ばれる、アルゴリズムを使用するクライアントとは独立してアルゴリズムを変更できます。
戦略パターンはオブジェクトの行動パターンです。

モードの動機:

タスクを完了するにはさまざまな方法があり、それぞれの方法は、さまざまな環境や条件に応じて、さまざまな戦略を選択できます。
ソフトウェア開発でも同様の状況がよく発生します。この場合、システムが柔軟にソリューションを選択し、新しいソリューションを簡単に追加できるようにするために、設計パターンを使用できます。
ソフトウェア システムでは、検索や並べ替えなど、特定の機能を実現できるアルゴリズムが多数あります。一般的な方法は、クラス内にハードコーディングすることです。複数の検索アルゴリズムを提供する必要がある場合は、これらのアルゴリズムを組み合わせることができます。これをクラスに記述し、そのクラス内で複数のメソッドを提供します。各メソッドは特定の検索アルゴリズムに対応します。もちろん、これらの検索アルゴリズムを統一メソッドにカプセル化して、if...else. などの条件判断ステートメントを使用することもできます。選択してください。これら 2 つの実装方法をハード コーディングと呼びます。新しい検索アルゴリズムを追加する必要がある場合は、カプセル化されたアルゴリズム クラスのソース コードを変更して、検索アルゴリズムを変更する必要があります。また、クライアントの呼び出しコードも変更する必要があります。このアルゴリズム クラスは、多数の検索アルゴリズムをカプセル化します。このタイプのコードはより複雑になり、保守が困難になります。

ロール分析:

抽象戦略ロール: Strategy クラス。通常はインターフェイスまたは抽象クラスによって実装されます。
特定の戦略の役割: 関連するアルゴリズムと動作のパッケージ化。
環境ロール: 戦略クラスへの参照を保持し、最終的にそれをクライアントに呼び出します。

UML クラス図:

コード実装:

<?phpheader("Content-type:text/html;Charset=utf-8");//抽象策略接口abstract class Strategy{    abstract function wayToSchool();}//具体策略角色class BikeStrategy extends Strategy{    function wayToSchool(){         echo "骑自行车去上学";    }}class BusStrategy extends Strategy{    function wayToSchool(){         echo "乘公共汽车去上学";    }}class TaxiStrategy extends Strategy{    function wayToSchool(){         echo "骑出租车去上学";    }}//环境角色class Context{    private $strategy;    //获取具体策略    function getStrategy($strategyName){        try{            $strategyReflection = new ReflectionClass($strategyName);            $this->strategy = $strategyReflection->newInstance();        }catch(ReflectionException $e){             $this->strategy = "";         }           }    function goToSchool(){        $this->strategy->wayToSchool();        // var_dump($this->strategy);    }}//测试$context = new Context();$context->getStrategy("BusStrategy");$context->goToSchool(); ?>

利点:

1. 戦略パターンは、関連するアルゴリズム ファミリを管理する方法を提供します。ポリシー クラスの階層は、アルゴリズムまたは動作のファミリーを定義します。継承を適切に使用すると、共通のコードを親クラスに転送できるため、コードの重複を回避できます。
2. 戦略パターンは、継承関係を置き換える方法を提供し、さまざまなアルゴリズムや動作を処理できます。戦略パターンを使用していない場合、アルゴリズムまたは動作を使用する環境クラスにはいくつかのサブクラスがあり、各サブクラスが異なるアルゴリズムまたは動作を提供する可能性があります。ただし、この方法では、アルゴリズムまたは動作のユーザーがアルゴリズムまたは動作自体と混同されます。どのアルゴリズムを使用するか、またはどの動作を実行するかを決定するロジックが、アルゴリズムや動作のロジックと混合され、独立して進化することができなくなります。継承により、アルゴリズムや動作を動的に変更することができなくなります。
3. ストラテジー モードを使用すると、複数の条件付き転送ステートメントの使用を回避できます。
複数の転送ステートメントは保守が容易ではありません。どのアルゴリズムや動作を採用するかというロジックと、それらを 1 つの複数の転送ステートメントにまとめます。これは、継承を使用するよりも原始的で簡単です。後ろに。

短所:

1. クライアントはすべての戦略クラスを理解し、どの戦略クラスを使用するかを決定する必要があります。
これは、適切なタイミングで適切なアルゴリズム クラスを選択するために、クライアントがこれらのアルゴリズムの違いを理解する必要があることを意味します。言い換えれば、戦略パターンは、クライアントがすべてのアルゴリズムまたは動作を知っている場合にのみ適しています。
2. 戦略パターンは多くの戦略クラスを作成し、特定の戦略クラスごとに新しいクラスが生成されます。
場合によっては、環境依存の状態をクライアントに保存することでポリシー クラスを共有可能に設計できるため、ポリシー クラスのインスタンスをさまざまなクライアントで使用できるようになります。つまり、フライウェイト パターンを使用してオブジェクトの数を減らすことができます。