文档章节

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

We911
 We911
发布于 2017/02/08 10:17
字数 3514
阅读 5
收藏 0

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

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

本文转载自:http://blog.csdn.net/liduanw/article/details/8195754

共有 人打赏支持
We911
粉丝 1
博文 63
码字总数 0
作品 0
深圳
程序员
java设计模式-- 单例模式

在很久之前,也就是在大二暑假的时候,那时候看马士兵的视频教程中有提到很多的设计模式。 java的设计模式大致可以分为3大类,23种设计模式。 其中,创建型模式有5种:单例模式、建造者模式、...

爱学习的逃课君
2014/11/27
0
0
javascript 设计模式之工厂(Factory)模式

工厂模式介绍 工厂模式是一个创建型的模式,主要就是创建对象。其中工厂模式又分为简单工厂模式和抽象工厂模式。简单工厂模式是通过工厂方法确定创建 对应类型的对象。抽象工厂模式是通过子类...

hlxiong
2014/04/14
0
0
代理模式(Proxy Pattern):动态代理 - 最易懂的设计模式解析

前言 今天我来全面总结开发中最常用的设计模式 - 代理模式中的动态代理模式 其他设计模式介绍 1分钟全面了解“设计模式” 单例模式(Singleton) - 最易懂的设计模式解析 简单工厂模式(Sim...

Carson_Ho
04/09
0
0
JavaScript常用设计模式

设计模式 设计模式是一种在长时间的经验与错误中总结出来可服用的解决方案。 设计模式主要分为3类: 创建型设计模式:专注于处理对象的创建 Constructor构造器模式,Factory工厂模式,Singl...

a独家记忆
07/13
0
0
系统架构技能之设计模式-单件模式

一、开篇 其实我本来不是打算把系统架构中的一些设计模式单独抽出来讲解的,因为很多的好朋友也比较关注这方面的内容,所以我想通过我理解及平时项目中应用到的一 些常见的设计模式,拿出来给...

wbf961127
2017/11/12
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

内存模型是怎么解决缓存一致性的?

在再有人问你Java内存模型是什么,就把这篇文章发给他。这篇文章中,我们介绍过关于Java内容模型的来龙去脉。 我们在文章中提到过,由于CPU和主存的处理速度上存在一定差别,为了匹配这种差距...

Java填坑之路
16分钟前
1
0
vue-cli 3.0 初体验

最近复习了下vue,突然发现vue-cli已经更新到3.0版本了,并且变化蛮大,看来要不停的学习,真是一入前端深似海。 安装步骤: 1、全局安装 npm install -g @vue/cli Vue CLI 的包名称由 vue-...

tianyawhl
18分钟前
0
0
Angular进阶之路

【初级】会写页面,能出东西。 给定环境和 rest API,不用第三方库,能在十分钟内完成一个 master/detail 结构的带路由的应用(可以不管美观)。 知识点:Angular CLI、组件、路由、HTTP 服务...

陆小七的主页
20分钟前
0
0
Redis缓存数据库安全加固指导(一)

背景 在众多开源缓存技术中,Redis无疑是目前功能最为强大,应用最多的缓存技术之一,参考2018年国外数据库技术权威网站DB-Engines关于key-value数据库流行度排名,Redis暂列第一位,但是原生...

中间件小哥
20分钟前
0
0
百万级数据mysql分区

1. 什么是表分区? 表分区,是指根据一定规则,将数据库中的一张表分解成多个更小的,容易管理的部分。从逻辑上看,只有一张表,但是底层却是由多个物理分区组成。 2. 表分区与分表的区别 分表...

罗文浩
23分钟前
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部