研磨设计模式之策略模式-2

 

 

2  解决方案

2.1  策略模式来解决

        用来解决上述问题的一个合理的解决方案就是策略模式。那么什么是策略模式呢？

（1）策略模式定义
         定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。

（2）应用策略模式来解决的思路
        仔细分析上面的问题，先来把它抽象一下，各种计算报价的计算方式就好比是具体的算法，而使用这些计算方式来计算报价的程序，就相当于是使用算法的客户。
        再分析上面的实现方式，为什么会造成那些问题，根本原因，就在于算法和使用算法的客户是耦合的，甚至是密不可分的，在上面实现中，具体的算法和使用算法的客户是同一个类里面的不同方法。
        现在要解决那些问题，按照策略模式的方式，应该先把所有的计算方式独立出来，每个计算方式做成一个单独的算法类，从而形成一系列的算法，并且为这一系列算法定义一个公共的接口，这些算法实现是同一接口的不同实现，地位是平等的，可以相互替换。这样一来，要扩展新的算法就变成了增加一个新的算法实现类，要维护某个算法，也只是修改某个具体的算法实现即可，不会对其它代码造成影响。也就是说这样就解决了可维护、可扩展的问题。
        为了实现让算法能独立于使用它的客户，策略模式引入了一个上下文的对象，这个对象负责持有算法，但是不负责决定具体选用哪个算法，把选择算法的功能交给了客户，由客户选择好具体的算法后，设置到上下文对象里面，让上下文对象持有客户选择的算法，当客户通知上下文对象执行功能的时候，上下文对象会去转调具体的算法。这样一来，具体的算法和直接使用算法的客户是分离的。
        具体的算法和使用它的客户分离过后，使得算法可独立于使用它的客户而变化，并且能够动态的切换需要使用的算法，只要客户端动态的选择使用不同的算法，然后设置到上下文对象中去，实际调用的时候，就可以调用到不同的算法。

2.2  模式结构和说明

        策略模式的结构示意图如图1所示：


 

图1  策略模式结构示意图

Strategy：
        策略接口，用来约束一系列具体的策略算法。Context使用这个接口来调用具体的策略实现定义的算法。
ConcreteStrategy：
        具体的策略实现，也就是具体的算法实现。
Context：
        上下文，负责和具体的策略类交互，通常上下文会持有一个真正的策略实现，上下文还可以让具体的策略类来获取上下文的数据，甚至让具体的策略类来回调上下文的方法。

2.3  策略模式示例代码

（1）首先来看策略，也就是定义算法的接口，示例代码如下：

 

 

/**

 * 策略，定义算法的接口

 */

public interface Strategy {

    /**

     * 某个算法的接口，可以有传入参数，也可以有返回值

     */

    public void algorithmInterface();

}

 

（2）该来看看具体的算法实现了，定义了三个，分别是ConcreteStrategyA、ConcreteStrategyB、ConcreteStrategyC，示例非常简单，由于没有具体算法的实现，三者也就是名称不同，示例代码如下：

 

 

/**

 * 实现具体的算法

 */

public class ConcreteStrategyA implements Strategy {

    public void algorithmInterface() {

       //具体的算法实现   

    }

}

/**

 * 实现具体的算法

 */

public class ConcreteStrategyB implements Strategy {

    public void algorithmInterface() {

       //具体的算法实现   

    }

}

/**

 * 实现具体的算法

 */

public class ConcreteStrategyC implements Strategy {

    public void algorithmInterface() {

       //具体的算法实现   

    }

}

 

（3）再来看看上下文的实现，示例代码如下：

 

 

/**

 * 上下文对象，通常会持有一个具体的策略对象

 */

public class Context {

    /**

     * 持有一个具体的策略对象

     */

    private Strategy strategy;

    /**

     * 构造方法，传入一个具体的策略对象

     * @param aStrategy 具体的策略对象

     */

    public Context(Strategy aStrategy) {

       this.strategy = aStrategy;

    }

    /**

     * 上下文对客户端提供的操作接口，可以有参数和返回值

     */

    public void contextInterface() {

       //通常会转调具体的策略对象进行算法运算

       strategy.algorithmInterface();

    }

}

 

 2.4  使用策略模式重写示例

        要使用策略模式来重写前面报价的示例，大致有如下改变：

• 首先需要定义出算法的接口。
• 然后把各种报价的计算方式单独出来，形成算法类。
• 对于Price这个类，把它当做上下文，在计算报价的时候，不再需要判断，直接使用持有的具体算法进行运算即可。选择使用哪一个算法的功能挪出去，放到外部使用的客户端去。
  

        这个时候，程序的结构如图2所示：

 图2  使用策略模式实现示例的结构示意图

（1）先看策略接口，示例代码如下：

 

 

/**

 * 策略，定义计算报价算法的接口

 */

public interface Strategy {

    /**

     * 计算应报的价格

     * @param goodsPrice 商品销售原价

     * @return 计算出来的，应该给客户报的价格

     */

    public double calcPrice(double goodsPrice);

}

 

（2）接下来看看具体的算法实现，不同的算法，实现也不一样，先看为新客户或者是普通客户计算应报的价格的实现，示例代码如下：

 

 

/**

 * 具体算法实现，为新客户或者是普通客户计算应报的价格

 */

public class NormalCustomerStrategy implements Strategy{

    public double calcPrice(double goodsPrice) {

       System.out.println("对于新客户或者是普通客户，没有折扣");

       return goodsPrice;

    }

}

 

再看看为老客户计算应报的价格的实现，示例代码如下：

 

 

/**

 * 具体算法实现，为老客户计算应报的价格

 */

public class OldCustomerStrategy implements Strategy{

    public double calcPrice(double goodsPrice) {

       System.out.println("对于老客户，统一折扣5%");

       return goodsPrice*(1-0.05);

    }

}

再看看为大客户计算应报的价格的实现，示例代码如下：

 

 

/**

 * 具体算法实现，为大客户计算应报的价格

 */

public class LargeCustomerStrategy implements Strategy{

    public double calcPrice(double goodsPrice) {

       System.out.println("对于大客户，统一折扣10%");

       return goodsPrice*(1-0.1);

    }

}

 

（3）接下来看看上下文的实现，也就是原来的价格类，它的变化比较大，主要有：

• 原来那些私有的，用来做不同计算的方法，已经去掉了，独立出去做成了算法类
• 原来报价方法里面，对具体计算方式的判断，去掉了，让客户端来完成选择具体算法的功能
• 新添加持有一个具体的算法实现，通过构造方法传入
• 原来报价方法的实现，变化成了转调具体算法来实现

示例代码如下：

 

 

/**

 * 价格管理，主要完成计算向客户所报价格的功能

 */

public class Price {

    /**

     * 持有一个具体的策略对象

     */

    private Strategy strategy = null;

    /**

     * 构造方法，传入一个具体的策略对象

     * @param aStrategy 具体的策略对象

     */

    public Price(Strategy aStrategy){

       this.strategy = aStrategy;

    }  

    /**

     * 报价，计算对客户的报价

     * @param goodsPrice 商品销售原价

     * @return 计算出来的，应该给客户报的价格

     */

    public double quote(double goodsPrice){

       return this.strategy.calcPrice(goodsPrice);

    }

}

（4）写个客户端来测试运行一下，好加深体会，示例代码如下：

 

 

public class Client {

    public static void main(String[] args) {

       //1：选择并创建需要使用的策略对象

       Strategy strategy = new LargeCustomerStrategy ();

       //2：创建上下文

       Price ctx = new Price(strategy);

      

       //3：计算报价

       double quote = ctx.quote(1000);

       System.out.println("向客户报价："+quote);

    }

}

       

        运行一下，看看效果。
        你可以修改使用不同的策略算法具体实现，现在用的是LargeCustomerStrategy，你可以尝试修改成其它两种实现，试试看，体会一下切换算法的容易性。

 

 

未完待续......

评论

27 楼 chjavach 2010-09-29  

wuqingjiang 写道

博主：请教个问题，如果我直接使用：
Strategy strategy = new LargeCustomerStrategy ();  
double quote=strategy.calcPrice(1000);
System.out.println("向客户报价："+quote);
不加Context类，这样不可以吗？请指教？谢谢！

你看看后面的本质分析,这个问题就清楚了

26 楼 wuqingjiang 2010-09-28  

博主：请教个问题，如果我直接使用：
Strategy strategy = new LargeCustomerStrategy ();  
double quote=strategy.calcPrice(1000);
System.out.println("向客户报价："+quote);
不加Context类，这样不可以吗？请指教？谢谢！

25 楼 shehun 2010-08-13  

chjavach 写道

zoujialiang 写道

看了楼主的模式，觉得很不错，但是感觉策略模式和工厂方法模式很相近，都是抽象出一个类，能后具体的实现交给客户自己传入对应的子类去实现。如果这样的话为什么要分成两个模式？迷惑中，期望楼主能帮我解释下，非常感谢！

    从设计上来讲,基本上所有的模式干的事情都很类似,无外乎:抽象、封装、分离，使得类的职责更清晰、更单一、技术边界更明确，动用的手段无非是继承、组合、多态等等。因此看上去相似是很有可能的。
    但是它们各自的目的不一样，实现手法不一样，应用场景不一样，本质也不一样，因此你在看得时候，要从这些方面去思考和分辨。
    比如你说的策略模式和工厂方法模式，策略的目的是分离算法，实现手法是对象组合；而工厂方法模式的目的是创建对象，实现手法是继承。
    权当抛砖引玉，更多的还得你深入的去思考。

关于你说的策略是分离算法，实现手法是对象组合，而工厂方法模式的目的是创建对象，实现手法是继承。这两句话不是很理解，对于而工厂方法模式的目的是创建对象，实现手法是继承。这个还能理解一些，主要是子类去实现父类。请楼主帮忙解释一下，最好拿个例子讲解一下，谢谢。

24 楼 zoujialiang 2010-07-12  

谢谢博主的解答，经过博主的思路点拨后，以前本人都是听大家都说设计模式很好才去学习设计模式，为了设计模式而设计模式，没有结合实际的项目而去理解设计模式的差异和各自的优点，所以才形成各个模式都差不多的思想，以后通过博主的理解角度：目的不一样，实现手法不一样，应用场景不一样，本质也不一样去理解设计模式，相信应该会对它们有更深入的理解了，用起来更能得心应手了，谢谢博主，期待后面的模式。。。。

23 楼 chjavach 2010-07-09  

当然也使得程序结构更合理，更灵活，真正做到可维护、可扩展、可配置

22 楼 chjavach 2010-07-09  

zoujialiang 写道

看了楼主的模式，觉得很不错，但是感觉策略模式和工厂方法模式很相近，都是抽象出一个类，能后具体的实现交给客户自己传入对应的子类去实现。如果这样的话为什么要分成两个模式？迷惑中，期望楼主能帮我解释下，非常感谢！

    从设计上来讲,基本上所有的模式干的事情都很类似,无外乎:抽象、封装、分离，使得类的职责更清晰、更单一、技术边界更明确，动用的手段无非是继承、组合、多态等等。因此看上去相似是很有可能的。
    但是它们各自的目的不一样，实现手法不一样，应用场景不一样，本质也不一样，因此你在看得时候，要从这些方面去思考和分辨。
    比如你说的策略模式和工厂方法模式，策略的目的是分离算法，实现手法是对象组合；而工厂方法模式的目的是创建对象，实现手法是继承。
    权当抛砖引玉，更多的还得你深入的去思考。

21 楼 zoujialiang 2010-07-07  

看了楼主的模式，觉得很不错，但是感觉策略模式和工厂方法模式很相近，都是抽象出一个类，能后具体的实现交给客户自己传入对应的子类去实现。如果这样的话为什么要分成两个模式？迷惑中，期望楼主能帮我解释下，非常感谢！

20 楼 seawenzhu 2010-07-07  

期待楼主对设计模式的一一讲解。

19 楼 chjavach 2010-07-06  

ssooss 写道

感觉本例中，跟依赖注入也很像，三种策略假设是容器生成的对象，那么 Price 的内部成员即为外部注入的。而注入的依据为客户所选择的类型。
不知然否？？？

可以这么实现,就相当于由客户端来选择策略,而客户端又使用Ioc/DI来实现

18 楼 ssooss 2010-07-06  

感觉本例中，跟依赖注入也很像，三种策略假设是容器生成的对象，那么 Price 的内部成员即为外部注入的。而注入的依据为客户所选择的类型。
不知然否？？？

17 楼 zha_zi 2010-07-06  

能写出更经典的东西

16 楼 zha_zi 2010-07-06  

楼主讲的比较透彻，希望把比较有争议的模式讲的清楚一些，例如前一段有一篇博客追mm的23种模式中的门面模式，下边网友评论乱七八糟，有的说经典，有的说没有说出要害，感觉楼主的设计功力了得

15 楼 chjavach 2010-07-01  

To  rentianchou、 452mian、 po_534兄：谢谢你们的支持，不过世界之大，无奇不有，见怪不怪，其怪也就自败了

14 楼 tigers20010 2010-06-28  

po_534 写道

还有看不惯别人写得好而瞎踩的鸟事?真是林子大了呀.
踩也是可以的,写点理由出来嘛,让大家都学习学习,也是好事情啊!
反正我是觉得博主写得好,非常的好,虽然语言不是那么诙谐生动,但是从知识的广大、深度、实用性上，是我看过的同类型中最好的，因此，我强烈顶博主

我似乎在《大话设计模式》这本书上见过的。呵呵。

13 楼 po_534 2010-06-26  

还有看不惯别人写得好而瞎踩的鸟事?真是林子大了呀.
踩也是可以的,写点理由出来嘛,让大家都学习学习,也是好事情啊!
反正我是觉得博主写得好,非常的好,虽然语言不是那么诙谐生动,但是从知识的广大、深度、实用性上，是我看过的同类型中最好的，因此，我强烈顶博主

12 楼 452mian 2010-06-26  

    楼上的老兄正解,或许是"同业竞争",写模式的又不只是楼主一个,写得好了,难免犯忌,总有人会来捣乱的,呵呵.
    因此我看博客的时候,很少去关注踩的,而是看顶的,还有大家的评论,说句实话,我是很懒的,不是因为楼主确实写得好,我才懒得写东西呢.
    我从工厂方法模式1开始,一路看下来,很多收获,很多知识都是以前不太清晰的,楼主讲的很多东西,都是以前没有想过,或是理解的不清楚的,说实话,这是我看过的,对于工厂方法模式和策略模式讲解得最深入浅出,而且知识点广泛、深入、准确，确是上佳的文章。
     因此，强力顶楼主，希望再接再厉，整出更好的文章来！

11 楼 zhayong 2010-06-26  

讲解的思路很清晰 赞一个
这么多踩的就不太理解了 嫌太简单？还是嫉妒？
要是给为踩的仁兄能给点高见 大家受教一下就好了
也不枉楼主莫名奇妙被人踩了几脚  让我大敢不平

10 楼 zhayong 2010-06-26  

楼主好文 我原来对策略模式一知半解 看来这篇有点顿悟清晰的感觉

9 楼 qianfu_zhi 2010-06-25  

博主好谦虚啊,写得很好,顶之

8 楼 chjavach 2010-06-24  

这一篇有这么多朋友"踩",说明里面有写得不好的地方,希望这些兄弟不吝赐教，
指出缺点，不管对错，我一定虚心接受，有则改之，无则加勉，再次感谢大家的支持。