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

 

 

3.4  策略模式结合模板方法模式

        在实际应用策略模式的过程中，经常会出现这样一种情况，就是发现这一系列算法的实现上存在公共功能，甚至这一系列算法的实现步骤都是一样的，只是在某些局部步骤上有所不同，这个时候，就需要对策略模式进行些许的变化使用了。
        对于一系列算法的实现上存在公共功能的情况，策略模式可以有如下三种实现方式：

• 一个是在上下文当中实现公共功能，让所有具体的策略算法回调这些方法。
• 另外一种情况就是把策略的接口改成抽象类，然后在里面实现具体算法的公共功能。
• 还有一种情况是给所有的策略算法定义一个抽象的父类，让这个父类去实现策略的接口，然后在这个父类里面去实现公共的功能。

        更进一步，如果这个时候发现“一系列算法的实现步骤都是一样的，只是在某些局部步骤上有所不同”的情况，那就可以在这个抽象类里面定义算法实现的骨架，然后让具体的策略算法去实现变化的部分。这样的一个结构自然就变成了策略模式来结合模板方法模式了，那个抽象类就成了模板方法模式的模板类。
        在上一章我们讨论过模板方法模式来结合策略模式的方式，也就是主要的结构是模板方法模式，局部采用策略模式。而这里讨论的是策略模式来结合模板方法模式，也就是主要的结构是策略模式，局部实现上采用模板方法模式。通过这个示例也可以看出来，模式之间的结合是没有定势的，要具体问题具体分析。
        此时策略模式结合模板方法模式的系统结构如下图5所示：


                                    图5  策略模式结合模板方法模式的结构示意图
        还是用实际的例子来说吧，比如上面那个记录日志的例子，如果现在需要在所有的消息前面都添加上日志时间，也就是说现在记录日志的步骤变成了：第一步为日志消息添加日志时间；第二步具体记录日志。
        那么该怎么实现呢？
（1）记录日志的策略接口没有变化，为了看起来方便，还是示例一下，示例代码如下： 

 

/**

 * 日志记录策略的接口

 */

public interface LogStrategy {

    /**

     * 记录日志

     * @param msg 需记录的日志信息

     */

    public void log(String msg);

}

（2）增加一个实现这个策略接口的抽象类，在里面定义记录日志的算法骨架，相当于模板方法模式的模板，示例代码如下： 

 

/**

 * 实现日志策略的抽象模板，实现给消息添加时间

 */

public abstract class LogStrategyTemplate implements LogStrategy{

    public final void log(String msg) {

       //第一步：给消息添加记录日志的时间

       DateFormat df = new SimpleDateFormat(

"yyyy-MM-dd HH:mm:ss SSS");

       msg = df.format(new java.util.Date())+" 内容是："+ msg;

       //第二步：真正执行日志记录

       doLog(msg);

    }

    /**

     * 真正执行日志记录，让子类去具体实现

     * @param msg 需记录的日志信息

     */                                 

    protected abstract void doLog(String msg);

}

（3）这个时候那两个具体的日志算法实现也需要做些改变，不再直接实现策略接口了，而是继承模板，实现模板方法了。这个时候记录日志到数据库的类，示例代码如下： 

 

/**

 * 把日志记录到数据库

 */

public class DbLog extends LogStrategyTemplate{

    //除了定义上发生了改变外，具体的实现没变

    public void doLog(String msg) {   

       //制造错误

       if(msg!=null && msg.trim().length()>5){

           int a = 5/0;

       }

       System.out.println("现在把 '"+msg+"' 记录到数据库中");

    }

}

同理实现记录日志到文件的类如下： 

 

/**

 * 把日志记录到数据库

 */

public class FileLog extends LogStrategyTemplate{

    public void doLog(String msg) {

       System.out.println("现在把 '"+msg+"' 记录到文件中");

    }

}

（4）算法实现的改变不影响使用算法的上下文，上下文跟前面一样，示例代码如下： 

 

/**

 * 日志记录的上下文

 */

public class LogContext {

    /**

     * 记录日志的方法，提供给客户端使用

     * @param msg 需记录的日志信息

     */

    public void log(String msg){

       //在上下文里面，自行实现对具体策略的选择

       //优先选用策略：记录到数据库

       LogStrategy strategy = new DbLog();

       try{

           strategy.log(msg);

       }catch(Exception err){

           //出错了，那就记录到文件中

           strategy = new FileLog();

           strategy.log(msg);

       }

    }  

}

（5）客户端跟以前也一样，示例代码如下： 

 

public class Client {

    public static void main(String[] args) {

       LogContext log = new LogContext();

       log.log("记录日志");

       log.log("再次记录日志");

    }

}

        运行一下客户端再次测试看看，体会一下，看看结果是否带上了时间。
        通过这个示例，好好体会一下策略模式和模板方法模式的组合使用，在实用开发中是很常见的方式。

3.5  策略模式的优缺点

• 定义一系列算法
      策略模式的功能就是定义一系列算法，实现让这些算法可以相互替换。所以会为这一系列算法定义公共的接口，以约束一系列算法要实现的功能。如果这一系列算法具有公共功能，可以把策略接口实现成为抽象类，把这些公共功能实现到父类里面，对于这个问题，前面讲了三种处理方法，这里就不罗嗦了。

避免多重条件语句
    根据前面的示例会发现，策略模式的一系列策略算法是平等的，可以互换的，写在一起就是通过if-else结构来组织，如果此时具体的算法实现里面又有条件语句，就构成了多重条件语句，使用策略模式能避免这样的多重条件语句。
    如下示例来演示了不使用策略模式的多重条件语句，示例代码如下：

 

 

public class OneClass {

    /**

     * 示范多重条件语句

     * @param type 某个用于判断的类型

     */

    public void oneMethod(int type){      

//使用策略模式的时候，这些算法的处理代码就被拿出去，

//放到单独的算法实现类去了，这里就不再是多重条件了

 

       if(type==1){                  

           //算法一示范

           //从某个地方获取这个s的值

           String s = "";

           //然后判断进行相应处理

           if(s.indexOf("a") > 0){

              //处理

           }else{

              //处理

           }

       }else if(type==2){

           //算法二示范

           //从某个地方获取这个a的值

           int a = 3;

           //然后判断进行相应处理

           if(a > 10){

              //处理

           }else{

              //处理

           }

       }

    }

}

• 更好的扩展性
      在策略模式中扩展新的策略实现非常容易，只要增加新的策略实现类，然后在选择使用策略的地方选择使用这个新的策略实现就好了。
• 客户必须了解每种策略的不同
      策略模式也有缺点，比如让客户端来选择具体使用哪一个策略，这就可能会让客户需要了解所有的策略，还要了解各种策略的功能和不同，这样才能做出正确的选择，而且这样也暴露了策略的具体实现。
• 增加了对象数目
      由于策略模式把每个具体的策略实现都单独封装成为类，如果备选的策略很多的话，那么对象的数目就会很可观。
• 只适合扁平的算法结构
      策略模式的一系列算法地位是平等的，是可以相互替换的，事实上构成了一个扁平的算法结构，也就是在一个策略接口下，有多个平等的策略算法，就相当于兄弟算法。而且在运行时刻只有一个算法被使用，这就限制了算法使用的层级，使用的时候不能嵌套使用。
      对于出现需要嵌套使用多个算法的情况，比如折上折、折后返卷等业务的实现，需要组合或者是嵌套使用多个算法的情况，可以考虑使用装饰模式、或是变形的职责链、或是AOP等方式来实现。

3.6  思考策略模式

1：策略模式的本质
        策略模式的本质：分离算法，选择实现。
        仔细思考策略模式的结构和实现的功能，会发现，如果没有上下文，策略模式就回到了最基本的接口和实现了，只要是面向接口编程的，那么就能够享受到接口的封装隔离带来的好处。也就是通过一个统一的策略接口来封装和隔离具体的策略算法，面向接口编程的话，自然不需要关心具体的策略实现，也可以通过使用不同的实现类来实例化接口，从而实现切换具体的策略。
        看起来好像没有上下文什么事情，但是如果没有上下文，那么就需要客户端来直接与具体的策略交互，尤其是当需要提供一些公共功能，或者是相关状态存储的时候，会大大增加客户端使用的难度。因此，引入上下文还是很必要的，有了上下文，这些工作就由上下文来完成了，客户端只需要与上下文交互就可以了，这样会让整个设计模式更独立、更有整体性，也让客户端更简单。
        但纵观整个策略模式实现的功能和设计，它的本质还是“分离算法，选择实现”，因为分离并封装了算法，才能够很容易的修改和添加算法；也能很容易的动态切换使用不同的算法，也就是动态选择一个算法来实现需要的功能了。

2：对设计原则的体现
        从设计原则上来看，策略模式很好的体现了开-闭原则。策略模式通过把一系列可变的算法进行封装，并定义出合理的使用结构，使得在系统出现新算法的时候，能很容易的把新的算法加入到已有的系统中，而已有的实现不需要做任何修改。这在前面的示例中已经体现出来了，好好体会一下。
        从设计原则上来看，策略模式还很好的体现了里氏替换原则。策略模式是一个扁平结构，一系列的实现算法其实是兄弟关系，都是实现同一个接口或者继承的同一个父类。这样只要使用策略的客户保持面向抽象类型编程，就能够使用不同的策略的具体实现对象来配置它，从而实现一系列算法可以相互替换。

3：何时选用策略模式
        建议在如下情况中，选用策略模式：

• 出现有许多相关的类，仅仅是行为有差别的情况，可以使用策略模式来使用多个行为中的一个来配置一个类的方法，实现算法动态切换
• 出现同一个算法，有很多不同的实现的情况，可以使用策略模式来把这些“不同的实现”实现成为一个算法的类层次
• 需要封装算法中，与算法相关的数据的情况，可以使用策略模式来避免暴露这些跟算法相关的数据结构
• 出现抽象一个定义了很多行为的类，并且是通过多个if-else语句来选择这些行为的情况，可以使用策略模式来代替这些条件语句

3.7  相关模式

• 策略模式和状态模式
      这两个模式从模式结构上看是一样的，但是实现的功能是不一样的。
      状态模式是根据状态的变化来选择相应的行为，不同的状态对应不同的类，每个状态对应的类实现了该状态对应的功能，在实现功能的同时，还会维护状态数据的变化。这些实现状态对应的功能的类之间是不能相互替换的。
      策略模式是根据需要或者是客户端的要求来选择相应的实现类，各个实现类是平等的，是可以相互替换的。
      另外策略模式可以让客户端来选择需要使用的策略算法，而状态模式一般是由上下文，或者是在状态实现类里面来维护具体的状态数据，通常不由客户端来指定状态。
• 策略模式和模板方法模式
      这两个模式可组合使用，如同前面示例的那样。
      模板方法重在封装算法骨架，而策略模式重在分离并封装算法实现。
• 策略模式和享元模式
      这两个模式可组合使用。
      策略模式分离并封装出一系列的策略算法对象，这些对象的功能通常都比较单一，很多时候就是为了实现某个算法的功能而存在，因此，针对这一系列的、多个细粒度的对象，可以应用享元模式来节省资源，但前提是这些算法对象要被频繁的使用，如果偶尔用一次，就没有必要做成享元了。
  

策略模式结束,谢谢观赏!鞠躬ing

评论

14 楼 chjavach 2010-07-05  

谢谢各位的支持,继续努力!

13 楼 mococa 2010-07-04  

楼主写的不错，继续发挥

12 楼 dduoyishan 2010-07-03  

写得真棒,难得看到这么好的技术文章了,向前追看,

11 楼 raojl 2010-07-02  

vieri122 写道

期待接下来的。
例外貌似前面没有提到模板方法。

楼主说的是抽象模板，不是泛型编程

10 楼 yinxiangbing 2010-07-02  

从头到尾一直在读博主的博文，受益颇深。博主的经验和功底都是非常深厚的，虽然本人工作有几年的经验，和博主相比，相差甚远，希望将来能够像博主那样谦虚，技术和经验一样丰富。也许博主可能是教育机构的讲师，水平都很高滴哈。呵呵。

9 楼 ktex263 2010-07-02  

写得真是不错，好文章

8 楼 chjavach 2010-07-02  

to  vtrtbb 兄: 貌似你提的这个问题在策略模式-4里面提过吧,我看到有朋友回答了,就没有多说了。既然再次提出来了，谈点我的看法吧：

1：首先，策略模式并不是要完全替换掉if-else，也就是说，并不是有了策略模式，就不再写if-else了，其实，每个策略封装的是原来if-else中的功能处理代码，而不是if-else本身。再说了，if-else只是策略模式要解决的问题之一。

2：你提出的这个问题的核心本质是：如何进行策略的选择。
    对于策略模式而言，一般有两个地方来进行策略的选择，其一：是在使用策略模式的客户端来进行选择，等客户端选择好了，设置到策略模式的Context中即可，这种情况是把if-else移到策略模式的外部；其二是在策略模式的Context中进行选择。

3：既然是需要做选择，那么if-else是一种最简单的写法。如果希望不再出现if-else，也有很多方法来处理，但那已经不是策略模式所关心的内容了。

4：那么怎么处理就能够不再出现if-else呢？常见的方案有：
（1）简单点的，用反射：
    这种方案可以在数据库或者是配置文件里面配置，比如：
     姓名      工资支付方式
     张三      cn.abc.paytype.RMBStrategy
    李四      cn.abc.paytype.DollarStrategy
   
   这样在程序里面读到这些数据了，就可以循环这些数据，然后根据工资支付方式所配置的类，进行反射调用，当然调用的方法是预先定好的,这样就不会出现if-else了。

（2）复杂点的，还可以做成原型注册器，这个可能需要对原型模式很熟悉才行。大致思路是这样，在原型注册器里面注册很多原型，原型注册器可以用Map实现：
     原型的Key    原型
      人民币        一个人民币支付的策略对象实例
      美元          一个美元支付的策略对象实例

     运行期间，根据数据库里面的记录，这个时候数据库中的记录可能是这样的：
      姓名      工资支付方式
      张三      人民币
     李四      美元

      程序里面这么写：      
      PaytypeApi api = PrototypeRegister.get("具体的工资支付方式").clone();
     也就是根据每个人员的支付方式的设置，到原型注册器里面去查找并得到原型，然后通过克隆原型，得到支付方式的对象，接下来，就可以调用支付对象的具体的支付方法来实现工资支付了。

（3）当然还有其它的方式，这里全当抛砖引玉。


不知道是否能解答你心中的疑问。

7 楼 vtrtbb 2010-07-02  

还是点到为止，比如说结合你这个例子来说，怎么把if else 替换掉才是最关键的，但恰恰就没有写出来，

平心而论，这样的例子基本掌握java的人都能写出来

6 楼 shenmifeidie 2010-07-02  

5 楼 clctcx 2010-07-01  

日益杂乱的JavaEye,已经很少看到如此精彩、有内涵、有技术、有思想、有内容的技术型文章了，看看每天首页上那一堆的八卦之作，让人惊呼，JavaEye还是个技术型的网站吗

4 楼 vieri122 2010-07-01  

期待接下来的。
例外貌似前面没有提到模板方法。

3 楼 woniu1983 2010-07-01  

非常好， 模式看多了，做多了。 在项目实践中也会不知不觉地使用上各种模式，一开始还没察觉，回过头来一看原来是策略+工厂， O(∩_∩)O~

2 楼 rentianchou 2010-07-01  

客气 客气  哈哈

1 楼 452mian 2010-07-01  

博主又写新文章了,始终精彩,真是厉害.
这种使用方法，我们在开发中也用过，但没有博主理解得这么清晰。
另外，博主对策略模式本质的分析，真是好，我以前就很忽略上下文，也认为策略模式不过就是接口和实现，其实是我理解不到位，谢谢博主的好文章