策略模式

时间  2020-05-27
标签 策略 模式 繁體版
原文   原文链接

策略模式(Strategy)

1  场景问题

1.1  报价管理

        向客户报价，对于销售部门的人来说，这是一个很是重大、很是复杂的问题，对不一样的客户要报不一样的价格，好比：html

  • 对普通客户或者是新客户报的是全价java

  • 对老客户报的价格，根据客户年限，给予必定的折扣算法

  • 对大客户报的价格，根据大客户的累计消费金额，给予必定的折扣数据库

  • 还要考虑客户购买的数量和金额，好比：虽然是新用户，可是一次购买的数量很是大，或者是总金额很是高，也会有必定的折扣设计模式

  • 还有，报价人员的职务高低，也决定了他是否有权限对价格进行必定的浮动折扣ide

        甚至在不一样的阶段，对客户的报价也不一样，通常状况是刚开始比较高，越接近成交阶段，报价越趋于合理。 
        总之，向客户报价是很是复杂的，所以在一些CRM（客户关系管理）的系统中，会有一个单独的报价管理模块，来处理复杂的报价功能。 
        为了演示的简洁性，假定如今须要实现一个简化的报价管理，实现以下的功能： 
           （1）对普通客户或者是新客户报全价 
           （2）对老客户报的价格，统一折扣5% 
           （3）对大客户报的价格，统一折扣10% 
        该怎么实现呢？测试

1.2  不用模式的解决方案

        要实现对不一样的人员报不一样的价格的功能，无外乎就是判断起来麻烦点，也很少难，很快就有朋友能写出以下的实现代码，示例代码以下：this

/**
* 价格管理，主要完成计算向客户所报价格的功能
*/
public class Price {
    /**
    * 报价，对不一样类型的，计算不一样的价格
    * @param goodsPrice 商品销售原价
    * @param customerType 客户类型
    * @return 计算出来的，应该给客户报的价格
    */
    public double quote(double goodsPrice,String customerType){
       if(customerType.equals("普通客户 ")){
           System.out.println("对于新客户或者是普通客户，没有折扣 ");
           return goodsPrice;
       }else if(customerType.equals("老客户 ")){
           System.out.println("对于老客户，统一折扣 5%");
           return goodsPrice*(1-0.05);
       }else if(customerType.equals("大客户 ")){
           System.out.println("对于大客户，统一折扣 10%");
           return goodsPrice*(1-0.1);        
       }
       //其他人员都是报原价
       return goodsPrice;
    }
}

1.3  有何问题

        上面的写法是很简单的，也很容易想，可是仔细想一想，这样实现，问题可不小，好比：spa

  • 第一个问题：价格类包含了全部计算报价的算法，使得价格类，尤为是报价这个方法比较庞杂，难以维护。设计

        有朋友可能会想，这很简单嘛，把这些算法从报价方法里面拿出去，造成独 立的方法不就能够解决这个问题了吗？据此写出以下的实现代码，示例代码以下：

/**
* 价格管理，主要完成计算向客户所报价格的功能
*/
public class Price {
    /**
    * 报价，对不一样类型的，计算不一样的价格
    * @param goodsPrice 商品销售原价
    * @param customerType 客户类型
    * @return 计算出来的，应该给客户报的价格
    */
    public double quote(double goodsPrice,String customerType){
       if(customerType.equals("普通客户 ")){
           return this.calcPriceForNormal(goodsPrice);
       }else if(customerType.equals("老客户 ")){
           return this.calcPriceForOld(goodsPrice);
       }else if(customerType.equals("大客户 ")){
           return this.calcPriceForLarge(goodsPrice);       
       }
       //其他人员都是报原价
       return goodsPrice;
    }
    /**
    * 为新客户或者是普通客户计算应报的价格
    * @param goodsPrice 商品销售原价
    * @return 计算出来的，应该给客户报的价格
    */
    private double calcPriceForNormal(double goodsPrice){
       System.out.println("对于新客户或者是普通客户，没有折扣 ");
       return goodsPrice;
    }
    /**
    * 为老客户计算应报的价格
    * @param goodsPrice 商品销售原价
    * @return 计算出来的，应该给客户报的价格
    */
    private double calcPriceForOld(double goodsPrice){
       System.out.println("对于老客户，统一折扣 5%");
       return goodsPrice*(1-0.05);
    }
    /**
    * 为大客户计算应报的价格
    * @param goodsPrice 商品销售原价
    * @return 计算出来的，应该给客户报的价格
    */
    private double calcPriceForLarge(double goodsPrice){
       System.out.println("对于大客户，统一折扣 10%");
       return goodsPrice*(1-0.1); 
    }
}

 这样看起来，比刚开始稍稍好点，计算报价的方法会稍稍简单一点，这样维护起来也稍好一些，某个算法发生了变化，直接修改相应的私有方法就能够了。扩展起来也容易一点，好比要增长一个“战略合做客户”的类型，报价为直接8折，就只须要在价格类里面新增长一个私有的方法来计算新的价格，而后在计算报价的方法里面新添一个else-if便可。看起来彷佛很不错了。 
        真的很不错了吗？ 
        再想一想，问题仍是存在，只不过从计算报价的方法挪动到价格类里面了，假若有100个或者更多这样的计算方式，这会让这个价格类很是庞大，难以维护。并且，维护和扩展都须要去修改已有的代码，这是很很差的，违反了开-闭原则。

  • 第二个问题：常常会有这样的须要，在不一样的时候，要使用不一样的计算方式。

        好比：在公司周年庆的时候，全部的客户额外增长3%的折扣；在换季促销的时候，普通客户是额外增长折扣2%，老客户是额外增长折扣3%，大客户是额外增长折扣5%。这意味着计算报价的方式会常常被修改，或者被切换。 
        一般状况下应该是被切换，由于过了促销时间，又还回到正常的价格体系上来了。而如今的价格类中计算报价的方法，是固定调用各类计算方式，这使得切换调用不一样的计算方式很麻烦，每次都须要修改if-else里面的调用代码。 
        看到这里，可能有朋友会想， 那么到底应该如何实现，才可以让价格类中的计算报价的算法，能很容易的实现可维护、可扩展，又能动态的切换变化呢？

2  解决方案

2.1  策略模式来解决

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

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

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

2.2  模式结构和说明

wKiom1lh1LmAv70sAAEB0LsnqNQ713.png

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这个类，把它当作上下文，在计算报价的时候，再也不须要判断，直接使用持有的具体算法进行运算便可。选择使用哪个算法的功能挪出去，放到外部使用的客户端去。

  • wKiom1lh1gqSWAY6AAEB0LsnqNQ509.png

（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，你能够尝试修改为其它两种实现，试试看，体会一下切换算法的容易性。

3.1  容错恢复机制

        容错恢复机制是应用程序开发中很是常见的功能。那么什么是容错恢复呢？简单点说就是：程序运行的时候，正常状况下应该按照某种方式来作，若是按照某种方式来作发生错误的话，系统并不会崩溃，也不会就此不能继续向下运行了，而是有容忍出错的能力，不但能容忍程序运行出现错误，还提供出现错误后的备用方案，也就是恢复机制，来代替正常执行的功能，使程序继续向下运行。
        举个实际点的例子吧，好比在一个系统中，全部对系统的操做都要有日志记录，并且这个日志还须要有管理界面，这种状况下一般会把日志记录在数据库里面，方便后续的管理，可是在记录日志到数据库的时候，可能会发生错误，好比暂时连不上数据库了，那就先记录在文件里面，而后在合适的时候把文件中的记录再转录到数据库中。
        对于这样的功能的设计，就能够采用策略模式，把日志记录到数据库和日志记录到文件看成两种记录日志的策略，而后在运行期间根据须要进行动态的切换。
        在这个例子的实现中，要示范由上下文来选择具体的策略算法，前面的例子都是由客户端选择好具体的算法，而后设置到上下文中。
        下面仍是经过代码来示例一下。
（1）先定义日志策略接口，很简单，就是一个记录日志的方法，示例代码以下：

/**
 * 日志记录策略的接口
 */
public interface LogStrategy {
    /**
     * 记录日志
     * @param msg 需记录的日志信息
     */
    public void log(String msg);
}

（2）实现日志策略接口，先实现默认的数据库实现，假设若是日志的长度超过长度就出错，制造错误的是一个最多见的运行期错误，示例代码以下：

/**
* 把日志记录到数据库
*/
public class DbLog implements LogStrategy{
    public void log(String msg) {     
       //制造错误
       if(msg!=null && msg.trim().length()>5){
           int a = 5/0;
       }
       System.out.println("如今把 '"+msg+"' 记录到数据库中");
    }
}

接下来实现记录日志到文件中去，示例代码以下：

/**
* 把日志记录到文件
*/
public class FileLog implements LogStrategy{
    public void log(String msg) {
       System.out.println("如今把 '"+msg+"' 记录到文件中");
    }
}

（3）接下来定义使用这些策略的上下文，注意此次是在上下文里面实现具体策略算法的选择，因此不须要客户端来指定具体的策略算法了，示例代码以下：

wKiom1lh2B7zy1fTAAJxD4gimyk361.png

（4）看看如今的客户端，没有了选择具体实现策略算法的工做，变得很是简单，故意多调用一次，能够看出不一样的效果，示例代码以下：

wKiom1lh2JeBbsNKAAHzrMIevaI091.png

（5）小结一下，经过上面的示例，会看到策略模式的一种简单应用，也顺便了解一下基本的容错恢复机制的设计和实现。在实际的应用中，须要设计容错恢复的系统通常要求都比较高，应用也会比较复杂，可是基本的思路是差很少的。

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

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

  • 一个是在上下文当中实现公共功能，让全部具体的策略算法回调这些方法。

  • 另一种状况就是把策略的接口改为抽象类，而后在里面实现具体算法的公共功能。

  • 还有一种状况是给全部的策略算法定义一个抽象的父类，让这个父类去实现策略的接口，而后在这个父类里面去实现公共的功能。

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

wKiom1lh2vjx5zWtAAD3tykV-pk283.png

仍是用实际的例子来讲吧，好比上面那个记录日志的例子，若是如今须要在全部的消息前面都添加上日志时间，也就是说如今记录日志的步骤变成了：第一步为日志消息添加日志时间；第二步具体记录日志。
        那么该怎么实现呢？
（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  相关模式

  • 策略模式和状态模式
        这两个模式从模式结构上看是同样的，可是实现的功能是不同的。
        状态模式是根据状态的变化来选择相应的行为，不一样的状态对应不一样的类，每一个状态对应的类实现了该状态对应的功能，在实现功能的同时，还会维护状态数据的变化。这些实现状态对应的功能的类之间是不能相互替换的。
        策略模式是根据须要或者是客户端的要求来选择相应的实现类，各个实现类是平等的，是能够相互替换的。
        另外策略模式可让客户端来选择须要使用的策略算法，而状态模式通常是由上下文，或者是在状态实现类里面来维护具体的状态数据，一般不禁客户端来指定状态。

  • 策略模式和模板方法模式
        这两个模式可组合使用，如同前面示例的那样。
        模板方法重在封装算法骨架，而策略模式重在分离并封装算法实现。

  • 策略模式和享元模式
        这两个模式可组合使用。
        策略模式分离并封装出一系列的策略算法对象，这些对象的功能一般都比较单一，不少时候就是为了实现某个算法的功能而存在，所以，针对这一系列的、多个细粒度的对象，能够应用享元模式来节省资源，但前提是这些算法对象要被频繁的使用，若是偶尔用一次，就没有必要作成享元了。

转载至:http://sishuok.com/forum/blogPost/list/95.html

   cc老师的设计模式是我目前看过最详细最有实践的教程。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程