(3) デザインモデルのPHPプロジェクト適用（戦略モデル：ショッピングモールレジシステム）

1 戦略パターンの概要 戦略パターンは、一連のアルゴリズムを定義し、各アルゴリズムをカプセル化し、それらを交換可能にします。 Strategy パターンを使用すると、アルゴリズムを使用するクライアントとは独立してアルゴリズムを変更できます。

2 パターンの構成 1) 抽象戦略の役割 (Strategy):
Strategy クラス。通常はインターフェイスまたは抽象クラスによって実装されます。 本文 2) 具体的な戦略:
関連するアルゴリズムと動作をパッケージ化。

3) 環境の役割 (コンテキスト):
最終的にクライアントによって呼び出される戦略クラスへの参照を保持します。
アルゴリズムクラスを使用しています。コマンド モードのアルゴリズムは互いに独立しており、各コマンドによって実行される作業は異なります。戦略パターンも同じ働きをします。



4 パターンアーキテクチャ図

5 プログラムアーキテクチャ
1) 抽象的な戦略 (Strategy)

// 定义接口，定义了要实现的策略算法interface IStrategy{    // 算法方法    public function doFunction();}

2) 具体的な戦略 (ConcreteStrategy)

れー

3)環境クラス (Context)

// 具体A策略class ConcreteStrategyA implements IStrategy{    public function doFunction(){        echo '算法A实现';    }}// 具体B策略class ConcreteStrategyB implements IStrategy{    public function doFunction(){        echo '算法B实现';    }}// 具体C策略class ConcreteStrategyC implements IStrategy{    public function doFunction(){        echo '算法C实现';    }}

4) Client (クライアント)

// 环境类，维护一个Strategy应用class Context{    // 策略    private $_strategy = null;    public function __construct(IStrategy $strategy){        $this->_strategy = $strategy;    }    public function doWork(){        return $this->_strategy->doFunction();    }}

6 プロジェクトアプリケーション

6.1 要件の説明
ショッピングモールのレジシステムでは、商品には通常の料金がかかります。割引充電、リベート充電およびその他のモード (「Dahua 設計パターン」より)

6.2 需要分析
ニーズに応じて、充電操作は通常充電、割引充電、およびリベート充電すべてのインターフェース アルゴリズムとして設計できます。このインターフェイスを継承して、さまざまな戦略アルゴリズムを実装します。次に、ポリシーのインスタンスを維持するための環境クラスを設計します。

6.3 設計アーキテクチャ図

6.4 プログラムのソースコードのダウンロード
http://download.csdn.net/detail/clevercode/8700009

6.5 プログラムの説明

1) Strategy.php

りー

2) StrategyPattern.php

// 客户端类class Client{    public function main($data){        // A策略        $context = new Context(new ConcreteStrategyA());        $context->doWork();                // B策略        $context = new Context(new ConcreteStrategyB());        $context->doWork();                // C策略        $context = new Context(new ConcreteStrategyC());        $context->doWork();    }}

3) Strategy.php と StrategyPattern.php 内。さらに戦略を拡張する必要がある場合は、課金インターフェイスを継承してさらに多くのクラスを実装するだけで済みます。これは、単純なファクトリ パターンと組み合わせて使用​​されます。手順がより明確になります。

7 概要

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

3. ストラテジー モードを使用すると、複数の条件付き転送ステートメントの使用を回避できます。複数の転送ステートメントは保守が容易ではありません。どのアルゴリズムまたは動作を採用するかのロジックを 1 つの複数の転送ステートメントにまとめてリストします。これは継承方法よりも原始的で後進的です。 。

7.2 欠点:
1. クライアントはすべてのポリシー クラスを理解し、どれを使用するかを決定する必要があります。これは、適切なタイミングで適切なアルゴリズム クラスを選択するために、クライアントがこれらのアルゴリズムの違いを理解する必要があることを意味します。言い換えれば、戦略パターンは、クライアントがすべてのアルゴリズムまたは動作を知っている場合にのみ適しています。

2. 戦略パターンは多くの戦略クラスを作成し、特定の戦略クラスごとに新しいクラスが生成されます。場合によっては、環境に依存する状態をクライアントに保存することで、ポリシー クラスを共有可能に設計できるため、ポリシー クラスのインスタンスをさまざまなクライアントで使用できるようになります。つまり、Flyweight パターンを使用してオブジェクトの数を減らすことができます。

著作権声明:

1) オリジナル作品、「CleverCode's Blog」から転載する場合は、必ず次の元のアドレスを明記してください。そうでない場合は、著作権法的責任を負うことになります。

2) 元のアドレス: (再印刷する場合は、必ずこのアドレスを指定してください)。

3) もっとエキサイティングなコンテンツを求めて私のブログをフォローしてくださる皆様を歓迎します:。