php设计模式之策略模式

　　本例为转载文章，看到了一位前辈写的关于策略模式的解释，感觉写的非常棒。本人也找不出多好的例子来解释这种模式，于是转载这位前辈的文章，记录一下自己学习的历程。原文本地址：http://www.cnblogs.com/baochuan/archive/2012/02/27/2370008.html

　　介绍：

　　策略模式:定义了算法族,分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

　　封装:把行为用接口封装起来，我们可以把那些经常变化的部分，从当前的类中单独取出来，用接口进行单独的封装。

　　互相替换:我们封装好了接口，通过指定不同的接口实现类进行算法的变化。
 
　　思维导图：
　　
　　
我来解释下这个思维导图的过程：
1.Joe做了一套相当成功的模拟鸭子的游戏。设计了一个超类Duck,然后让各种鸭子继承这个类。
 
2.后来客户提出要让鸭子有飞的能力。所以Joe就在超类中加了个fly()方法，这样下面的子类都有飞行的行为。
   问题来了：1>原来Duck的子类中竟然有橡皮鸭，橡皮鸭是不会飞的。——Joe用重载的方式，把橡皮鸭的fly()方法设置为空.
                     2>覆盖fly()，我们看到了橡皮鸭的fly()里，没有任何代码，如果以后我们再添加别的不会飞的鸭子，那我么还要这么处理吗?——那么代码重复了!
 
3.上面2的方式我们知道是有问题的，所以Joe想到把Duck做成接口，这样每个子类必须实现Duck里的方法。这样就保证每个鸭子都能根据自己的需要添加行为。
     问题来了：产品经常处于更新中，规格也在不断的变化。导致每当有新鸭子的时候，Joe就要被迫检查一遍子类是否覆盖了fly()方法。——当你修改某个行为的时候，你必须得往下追踪并在每一个定义此行为的类中修改它。
 
4.综合以上问题，Joe想到了把那些变化的部分从不变化的位置中抽出来。比如，我们对fly()行为，做了单独的接口FlyBehavior。如果鸭子想要飞行功能的时候，我们就让鸭子实现FlyBehavior.
 
5.深造:我们想让鸭子有不同的飞行功能，让它在运行时候做不同的飞行动作。让鸭子类实现接口，只能让鸭子有一种行为。
所以Joe，想到用组合的防止，当鸭子需要其他飞行功能要求的时候，我们可以用setBehavior()方式，指定性的飞行方式。
 
　　代码：　
 1 <?php
 2 interface FlyBehavior{
 3     public function fly();
 4 }
 5  
 6 class FlyWithWings implements FlyBehavior{
 7     public function fly(){
 8         echo "Fly With Wings \n";
 9     }
10 }
11  
12 class FlyWithNo implements FlyBehavior{
13     public function fly(){
14         echo "Fly With No Wings \n";
15     }
16 }
17 class Duck{
18     private $_flyBehavior;
19     public function performFly(){
20         $this->_flyBehavior->fly();
21     }
22  
23     public function setFlyBehavior(FlyBehavior $behavior){
24         $this->_flyBehavior = $behavior;
25     }
26 }
27  
28 class RubberDuck extends Duck{
29 }
30 // Test Case
31 $duck = new RubberDuck();
32  
33 /*  想让鸭子用翅膀飞行 */
34 $duck->setFlyBehavior(new FlyWithWings());
35 $duck->performFly();            
36  
37 /*  想让鸭子不用翅膀飞行 */
38 $duck->setFlyBehavior(new FlyWithNo());
39 $duck->performFly();　
总的来说，我们在开发中的设计原则如下:
1.找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起;
2.针对接口编程，不针对实现编程;
3.多用组合，少用继承;
 
 优点：      

            1、 策略模式提供了管理相关的算法族的办法。

             策略类的等级结构定义了一个算法或行为族。

             恰当使用继承可以把公共的代码转移到父类里面，从而避免重复的代码。

            2、 策略模式提供了可以替换继承关系的办法。

               继承可以处理多种算法或行为。

               如果不是用策略模式，那么使用算法或行为的环境类就可能会有一些子类，每一个子类提供一个不同的算法或行为。但是，这样一来算法或行为的使用者就和算法或行为本身混在一起。决定使用哪一种算法或采取哪一种行为的逻辑就和算法或行为的逻辑混合在一起，从而不可能再独立演化。继承使得动态改变算法或行为变得不可能。

           3、 使用策略模式可以避免使用多重条件转移语句。

             多重转移语句不易维护，它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起，统统列在一个多重转移语句里面，比使用继承的办法还要原始和落后。

 缺点：

            1、客户端必须知道所有的策略类，并自行决定使用哪一个策略类。

             这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。

            2、 策略模式造成很多的策略类，每个具体策略类都会产生一个新类。

            有时候可以通过把依赖于环境的状态保存到客户端里面，而将策略类设计成可共享的，这样策略类实例可以被不同客户端使用。换言之，可以使用享元模式来减少对象的数量。

参考文章：

http://blog.csdn.net/jhq0113/article/details/45771863

https://my.oschina.net/shyl/blog/525844

posted @ 2016-11-28 13:49  NickBai  阅读(227)  评论(0)  编辑  收藏  举报