ケーススタディ:戦略モード

まず、デザインモード

  デザインパターンは、次の3つのカテゴリに分けることができます。

  Factory Methodパターン、Abstract Factoryパターン、シングルトン、Builderパターン、プロトタイプモデル:スキーマ、5つのカテゴリーの合計を作成します。

  構造モデル、7種類の合計:アダプタモード、装飾的なモード、プロキシモード、外観モード、ブリッジモード、組み合わせモード、フライ級。

  行動パターン、11種類の合計:Strategyパターン、モードを説明するためのテンプレートメソッドパターン、オブザーバーモード、イテレータパターン、責任のチェーン・モード、コマンドモード、メモモード状態モード、ビジターパターン、仲介モデル。

  次のように:(ネットワークからの画像を写真)について説明

  

第二に、戦略パターン

1.戦略パターンとは何ですか

  戦略モードアルゴリズムのパッケージである、とアルゴリズムの使用は、異なるオブジェクト管理に委任セグメンテーションアルゴリズム自体オフの責任である、と裁判官は複数の問題を解決する場合は、最終的に達成することができます。

  1.環境(コンテキスト)役割:戦略への参照を保持します。2.抽象戦略(ストラテジー)の役割:これは通常、インターフェースや抽象クラスによって実装、抽象的役割です。このロールは、すべてのクラスのインターフェイスに必要な具体的な戦略を提供します。3.具体的な戦略(ConcreteStrategy)役割:関連するアルゴリズムや振る舞いをパッケージ化。

  定義された戦略のインターフェイス - 多状態または他のコール戦略を使用して> - >異なる戦略クラスを実装します。

2.戦略モードの長所と短所

  長所:アルゴリズム自由に(ハイレベルのマスキングアルゴリズム、スイッチへの無料の役割)の使用を避けることを切り替えることができ、複数の条件付き(無料キャンセレーションアルゴリズムに影響を与えることなく、追加することができ、良好なスケーラビリティ(過度のアルゴリズムが同じ判断の非常に多くなる場合、それを維持することは困難です)全体の機能)。

  短所:ポリシーの数は(ヒトでの使用は、使用ポリシーを理解する必要があり、すべてのポリシーのクラスは、外部被ばくの必要があります(必要にアルゴリズムを増やす場合は、各ポリシーカテゴリの再利用は、非常に小さく、それが唯一のクラスを追加することができます)クラスを増加し、これは、追加が必要となりますモードは、工場出荷時のモード、プロキシモード)として、補完します。

3.戦略パターン例の説明

  私たちの配列出力例。

  出力シーケンスの出力配列、文字列や出力などの出力形式のJSON配列。各出力は、独立してポリシーとして、カプセル化することができます。

  適用される場合、アレイ等をデータベースに保存する必要があり、出力がシリアライズ方法であってもよいです。APPは、インタフェースに供給されるため、JSON出力文字列を使用することができます。他のプロシージャを呼び出す、直接出力配列形式。

の状況に3.1デザインパターンの存在なし

  在没有设计模式的情况,我们用一个类集中处理数组输出,如下:

 1 /**
 2  * 根据给定类型,将数组转换后输出
 3  */
 4 class Output
 5 {
 6     public function render($array, $type = '')
 7     {
 8         if ($type === 'serialize') {
 9             return serialize($array);
10         } elseif ($type === 'json') {
11             return json_encode($array);
12         } else {
13             return $array;
14         }
15     }
16 }

  客户端直接使用这个类来处理数组,就能达到效果:

 1 /**
 2  * 客户端代码
 3  */
 4 $test = ['a', 'b', 'c'];
 5 
 6 // 实例化输出类
 7 $output = new Output();
 8 
 9 // 直接返回数组
10 $data = $output->render($test, 'array');
11 
12 // 返回JSON字符串
13 $data = $output->render($test, 'json');

  这种方法的优点是简单、快捷,在小方案中使用非常合适。

  但是,如果是一个复杂方案,包括大量的处理逻辑需要封装,或者处理方式变动较大,则就显得混乱。当需要添加一种算法,就必须修改Output类,影响原有代码,可扩展性差。如果输出方式很多,if-else或switch-case语句也会很多,代码混乱难以维护。

3.2 使用策略模式解决问题

  首先,定义一系列的策略类,它们独立封装,并且遵循统一的接口。
  以后的维护过程中,下面的代码都不需修改了。如果需要增加输出方式,重新建一个类就可以了。
 1 /**
 2  * 策略接口
 3  */
 4 interface OutputStrategy
 5 {
 6     public function render($array);
 7 }
 8 
 9 /**
10  * 策略类1:返回序列化字符串
11  */
12 class SerializeStrategy implements OutputStrategy
13 {
14     public function render($array)
15     {
16         return serialize($array);
17     }
18 }
19 
20 /**
21  * 策略类2:返回JSON编码后的字符串
22  */
23 class JsonStrategy implements OutputStrategy
24 {
25     public function render($array)
26     {
27         return json_encode($array);
28     }
29 }
30 
31 /**
32  * 策略类3:直接返回数组
33  */
34 class ArrayStrategy implements OutputStrategy
35 {
36     public function render($array)
37     {
38         return $array;
39     }
40 }

  环境类:环境角色用来管理策略,实现不同策略的切换功能。同样,一旦写好,环境角色类以后也不需要修改了。

 1 /**
 2  * 环境角色类
 3  */
 4 class Output
 5 {
 6     private $outputStrategy;
 7 
 8     // 传入的参数必须是策略接口的子类或子类的实例
 9     public function __construct(OutputStrategy $outputStrategy)
10     {
11         $this->outputStrategy = $outputStrategy;
12     }
13 
14     public function renderOutput($array)
15     {
16         return $this->outputStrategy->render($array);
17     }
18 }

  客户端代码:在客户端中,策略模式通过给予不同的具体策略,来获取不同的结果。对于较为复杂的业务逻辑显得更为直观,扩展也更为方便。

 1 /**
 2  * 客户端代码
 3  */
 4 $test = ['a', 'b', 'c'];
 5 
 6 // 需要返回数组
 7 $output = new Output(new ArrayStrategy());
 8 $data = $output->renderOutput($test);
 9 
10 // 需要返回JSON
11 $output = new Output(new JsonStrategy());
12 $data = $output->renderOutput($test);

3.3 特点分析:

  策略模式主要用来分离算法,根据相同的行为抽象来做不同的具体策略实现。策略模式结构清晰明了、使用简单直观。并且耦合度相对而言较低,扩展方便。同时操作封装也更为彻底,数据更为安全。

  当然策略模式也有缺点,就是随着策略的增加,子类也会变得繁多。但缺点并不会影响系统运行,所以在复杂业务中应该考虑使用。

4. github版本库URL

  https://github.com/happyyouli/Strategy-mode

 

おすすめ

転載: www.cnblogs.com/happyyouli/p/12007929.html