商场收银软件
简单来说，就是根据单价数量计算出总价，同时要应对商场的各种促销活动。
例如，打九折，满300减100，积分等
通过之前简单工厂模式的学习，可以想到创建一个收费的父类，然后继承这个父类，完成每种促销活动的代码。再进一步思考可以把打九折，打八折等可以统一为打折子类，实例化时传入打折数。同理满多少减多少，初始化时需要两个参数。
面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。
简单工厂模式实现
UML类图
代码如下
收取现金抽象类
public abstract class CashSuper {
/**
* 收取现金
* @param money 原价
* @return 实际收取的价格
*/
public abstract double acceptMoney(double money);
}
正常收费类
public class CashNormal extends CashSuper {
/**
* 原价返回
* @param money 原价
* @return
*/
@Override
public double acceptMoney(double money) {
return money;
}
}
打折收费类
public class CashRebate extends CashSuper {
private double moneyRebate = 1;
/**
* 初始化时，必须输入折扣率
* @param moneyRebate
*/
public CashRebate(double moneyRebate) {
this.moneyRebate = moneyRebate;
}
@Override
public double acceptMoney(double money) {
return money * moneyRebate;
}
}
收费工厂类
public class CashFactory {
public static CashSuper createCashAccept(String type) {
CashSuper cashSuper = null;
switch (type) {
case "正常收费":
cashSuper = new CashNormal();
break;
case "满300减100":
cashSuper = new CashReturn(300, 100);
break;
case "打8折":
cashSuper = new CashRebate(0.8);
break;
}
return cashSuper;
}
}
简单工厂模式虽然也能解决这个问题，但这个模式只是解决对象的创建问题，而且由于工厂本身包括了所有的收费方式，商场是可能经常性地更改打折额度和返利额度，每次维护或扩展收费方式都要改动这个工厂，以致代码需要重新编译部署。面对算法的时常变动，可以使用策略模式。
策略模式
策略模式（Strategy）：它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。[DP]
商场收银时如何促销，用打折还是返利，其实都是一些算法，用工厂来生成算法对象，并没有错，但算法本身只是一种策略，最重要的是这些算法是随时都可能互相替换的，这就是变化点，而封装变化点是面向对象的一种很重要的思维方式。
UML类图
代码如下
抽象算法类
public abstract class Strategy {
/**
* 算法方法
*/
public abstract void algorithmInterface();
}
具体的算法策略A
public class ConcreteStrategyA extends Strategy {
@Override
public void algorithmInterface() {
print("算法A的实现");
}
}
策略B、策略C代码略
Context上下文
public class Context {
private Strategy strategy;
/**
* 构造函数
* @param strategy 具体的策略对象
*/
public Context(Strategy strategy) {
this.strategy = strategy;
}
/**
* 根据具体的策略对象，调用其算法的方法
*/
public void contextInterface() {
strategy.algorithmInterface();
}
}
调用代码
public static void main(String[] args) {
Context context;
//实例化不同的策略
context = new Context(new ConcreteStrategyA());
context.contextInterface();
context = new Context(new ConcreteStrategyB());
context.contextInterface();
}
策略模式实现
根据策略模式代码改写之前用简单工厂模式实现的商场促销，可以把简单工厂模式和策略模式结合起来。
CashContext代码如下：
public class CashContext {
private CashSuper cashSuper;
public CashContext(String type) {
CashSuper cashSuper = null;
switch (type) {
case "正常收费":
cashSuper = new CashNormal();
break;
case "满300减100":
cashSuper = new CashReturn(300, 100);
break;
case "打8折":
cashSuper = new CashRebate(0.8);
break;
}
this.cashSuper = cashSuper;
}
public double getResult(double money) {
return cashSuper.acceptMoney(money);
}
}
前后对比
//简单工厂用法
CashSuper cashSuper = CashFactory.createCashAccept("正常收费");
cashSuper.acceptMoney(100)
//策略模式与简单工厂结合
CashContext cashContext = new CashContext("正常收费");
cashContext.getResult(100);
简单工厂模式需要让客户端认识两个类，CashSuper和CashFactory，而策略模式与简单工厂结合的用法，只需认识CashContext对象，耦合更低。
客户端实例化的是CashContext的对象，调用的是CashContext的方法getResult，使具体的收费算法彻底与客户端分离。连算法的父类CashSuper都不让客户端认识了。
策略模式解析
策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合[DPE]
策略模式的Strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能[DP]
对于打折、返利或者其他的算法，其实都是对实际商品收费的一种计算方式，通过继承，可以得到它们的公共功能。公共功能是获得计算费用的结果，使得算法间有了抽象的父类。
另外一个 策略模式的优点是简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试[DPE]
策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性[DPE]
在基本的策略模式中，选择所用具体实现的职责由客户端对象承担，并转给策略模式的Context对象[DPE] 这本身并没有解除客户端需要选择判断的压力，而策略模式与简单工厂模式结合后，选择具体实现的职责也可以由Context来承担，这就最大化减轻了客户端的职责。
总结
策略模式主要用于封装算法，可以在不影响客户使用算法的前提下完成算法的修改或替换等操作。适用于算法经常会变的场景，就像示例中商场的促销策略。
