二、策略模式——设计模式学习笔记

作为一个编程菜鸟，过去在学习设计模式的时候，老师给推荐了一本《大话设计模式》。阅读以后受益匪浅，可惜当初没有坚持看完。
最近有时间了，又重新捡起来学习了一遍，整理了一下笔记，由于本人能力有限，欢迎大家批评指正。

1.策略模式 Strategy pattern

策略模式定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户（策略模式让算法独立于使用它的客户而独立变化）。

面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。

以商场收银时如何促销为例，用打折还是返利，其实都是一些算法，若用工厂来生成算法对象，这没有错，但算法本身只是一种策略，最重要的是这些算法是随时都可能互相替换的，这就是变化点，而封装变化点是面向对象的一种很重要的思维方式。

策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。

策略模式的Stategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能。

策略模式的优点是简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。

策略模式封装了变化，它就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要再不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。

任何需求的变更都是需要成本的。

2.uml类图

3.组成：

（1）抽象策略角色

策略类，通常由一个接口或者抽象类实现。定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，Context使用这个接口调用不同的算法，一般使用接口或抽象类实现

（2）具体策略角色

包装了相关的算法和行为。实现了Strategy定义的接口，提供具体的算法实现

（3）环境角色

持有一个策略类的引用，最终给客户端调用，需要使用ConcreteStrategy提供的算法，内部维护一个Strategy实例，负责动态设置运行时Strategy具体的实现算法，辅助跟Strategy之间的交互和数据传递。

4.优缺点

（1）优点

策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把公共的代码转移到父类里面，从而避免重复的代码。

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

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

（2）缺点

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

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

5.实例 策略模式+简单工厂

（1）需求

商场收银时采取若干促销方案，如打折、促销。

（2）uml类图

（3）代码

a.优惠算法类

package com.longinus.sp;
public abstract class CashSuper {
public abstract double acceptCash(double cash);
}

b.具体优惠算法类

package com.longinus.sp;
public class CashNormal extends CashSuper {
@Override
public double acceptCash(double cash) {
// TODO 自动生成的方法存根
return cash;
}
}

package com.longinus.sp;
public class CashRebate extends CashSuper{
private int rebate;

public CashRebate(int rebate) {
// TODO 自动生成的构造函数存根
this.rebate = rebate;
}

@Override
public double acceptCash(double cash) {
// TODO 自动生成的方法存根
return cash * rebate / 10;
}
}

package com.longinus.sp;
public class CashReturn extends CashSuper{
private int condition;
private int returnCash;

public CashReturn(int condition,int returnCash) {
// TODO 自动生成的构造函数存根
this.condition = condition;
this.returnCash = returnCash;
}

@Override
public double acceptCash(double cash) {
// TODO 自动生成的方法存根
return cash - Math.floor(cash/condition)*returnCash;
}
}

c.优惠应用类

package com.longinus.sp;
public class CashContext {
CashSuper cs = new CashNormal();

public CashContext(String conditionOfStaticFactory) {
// TODO 自动生成的构造函数存根
switch (conditionOfStaticFactory) {
case "无优惠":
cs = new CashNormal();
break;

case "打折":
cs = new CashRebate(7);
break;

case "返利":
cs = new CashReturn(400, 100);
break;
default:

break;
}
}

public double getResult(double cash){
return cs.acceptCash(cash);
}
}

d.测试类

package com.longinus.sp;
public class Test {
public static void main(String[] args) {
CashContext cc = new CashContext("无优惠");
System.out.println(cc.getResult(1000));
cc = new CashContext("打折");
System.out.println(cc.getResult(1000));
cc = new CashContext("返利");
System.out.println(cc.getResult(1000));
}
}

e.输出结果

1000.0
700.0
800.0

6.简单工厂与策略模式的区别

简单工厂，即静态工厂方法，其中工厂并不一定是一个单独的类，亦或是作为一个方法实现，其核心思想是根据外界信息创建怎样的对象，重点在于对象的创建。而策略模式关注的是策略或者说算法，通过抽象出不同算法之间的抽象类或接口，实现算法之间的独立，降低了算法与算法调用之间的耦合，方便了不同算法的维护、拓展与复用。

Context类注重的是具体需求所使用的算法的调用，而不是根据需求所需的算法的创建，其中类中，根据需求所需的算法所创建具体对象的部分可以使用静态工厂方法，此时客户端无需关心算法对象的创建和实现。

如果单纯采用简单工厂，则需要让客户端认识两个类优惠算法抽象类和工厂类，如果单纯采用策略模式，客户端需要判断用哪一个算法，若要把这个判断的过程转移走则需要工厂类，而将策略模式与简单工厂结合，将工厂类改写为静态工厂方法与优惠应用类的构造方法结合，客户端就只需要认识一个类即优惠应用类即可，耦合更加降低。