【设计模式】阿里终面:你觉得这个例子是策略模式吗？
什么是策略模式？
策略模式，举几个贴近生活的例子：当我们出行的时候，不同的出行方式就是不同的策略，例如走路、开车、骑自行车、坐飞机、坐邮轮等等，每一种出行方式都代表着不同的费用和时间；当我们去商场超市的时候，可能正好打折，也可能正好满减，又或者积分返利等等**，这些都是策略！**
先来看看策略模式的定义：策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。
策略模式的精髓就在于将经常变化的一点提取出来，单独变成一类，并且各个类别可以相互替换和组合，类图关系如下：
结合策略模式的类图，可知策略模式主要由三个部分构成：抽象的策略类（所有具体的策略都需要继承它）、具体的策略类（实现了各种不同的策略方法）、上下文类或者说必备参数类（其中主要维护着一个具体策略类的引用，以及策略所必备的上下参数）。
策略模式通过context上下文类来自由的选择所要采取的方法:
public class AbstractContext {
AbstractStrategy strategy;
//初始化时传入具体的策略对象
public AbstractContext(AbstractStrategy strategy) {
this.strategy = strategy;
}
//上下文接口，调用策略的具体方法
public void ContextInterface() {
strategy.ItsInterface();
}
}
而对应的方法都是继承与同一个抽象的策略类：
public abstract class AbstractStrategy {
//留待子类自己实现
public void ItsInterface(){
}
}
具体的策略类实现在子类中进行重载，如下：
public class FakeStrategy extends AbstractStrategy{
@Override
//子类实现的具体方法
public void ItsInterface() {
System.out.println("I'm using this method");
}
}
具体实现
策略模式所要解决的问题主要是在多种算法极其相似的情况下，让对象根据上下文（context）进行具体实现的选择。例如正如我们开篇所提到的那样，选择出门的方式：骑车、开车、走路等等，甚至骑车一段时间、走路一段时间、坐飞机一段时间。
我觉得《大话设计模式》举的例子十分贴切：某商场搞促销活动，有打折活动、满减活动（两个可同时进行），并且打折的力度和满减的程度可能在今后需要进行修正，那么应当如何设计整个系统呢？
策略模式实现
假设现在商场有三种结算方式：正常结算、打折结算、返利结算。根据策略模式的思想，我们可以设计一个这样的系统：
- 上下文类
先创建一个抽象的上下文类，根据传入策略类来获得具体的优惠策略，调用getPrice()来获取最终需要支付的结果。
public class CashContext {
private CashAbstract CashAbstract;
public CashContext(CashAbstract CashAbstract) {
this.CashAbstract = CashAbstract;
}
public double getResult(double money) {
return CashAbstract.acceptCash(money);
}
}
- 抽象策略类
抽象策略类在这里指的是根据商场活动以及顾客的消费额来计算真正应该支付的金额：
public abstract class CashAbstract {
public abstract double acceptCash(double money);
}
- 三种具体的策略子类
商场活动一共有三种：正常收费（无活动）、打折收费、返利收费，这里只给出返利收费的实现：
public class CashReturn extends CashAbstract {
//返利收费，初始化时必须输入返利条件以及返利金额
private double moneyCondition = 0.0;
private double moneyReturn = 0.0d;
public CashReturn(double moneyCondition, double moneyReturn) {
this.moneyCondition = moneyCondition;
this.moneyReturn = moneyReturn;
}
@Override
public double acceptCash(double money) {
double result = money;
if (money >= moneyCondition) {
result = money - Math.floor(money / moneyCondition) * moneyReturn;
}
return result;
}
}
- 测试一下我们的设计的收费系统
public class App {
public static void main(String[] args) {
CashContext cashContext = null;
Scanner scanner = new Scanner(System.in);
System.out.print("请输入活动内容：1是正常收费，2是返利收费，3是打折活动");
int in = scanner.nextInt();
String type = "";
switch (in) {
case 1:
cashContext = new CashContext(new CashNormal());
type += "正常收费";
break;
case 2:
cashContext = new CashContext(new CashReturn(300, 100));
type += "满300返100";
break;
case 3:
cashContext = new CashContext(new CashRebate(0.8));
type += "打8折";
break;
default:
System.out.println("请输入1/2/3");
break;
}
double totalPrices = 0;
System.out.print("请输入单价：");
double price = scanner.nextDouble();
System.out.print("请输入数量：");
double num = scanner.nextDouble();
totalPrices = cashContext.getPrice(price * num);
System.out.println("单价：" + price + "，数量：" + num + "，类型：" + type + "，合计：" + totalPrices);
scanner.close();
}
}
正常活动模式：
返利活动模式：
打折活动模式：
可见，我们设计的收费系统是没问题的。
策略模式+简单工厂
虽然，上述策略模式的实现能够正常运行，且满足当前的需求。但是，代码无错便是优吗？当然不是！
仔细想想，按照上文代码的实现思路，如果新增一个活动类别，岂不是还需要在switch-case种加一个分支？
并且，客户端代码里“耦合”了多个对象：cashContext与cashNormal、cashReturn、CashRebate。客户端耦合的对象越多，之后的修改和拓展就会越来越困难。
在之前介绍三种工厂模式的时候我们提到，当遇到这种switch-case语句的时候，往往都可以使用简单工厂模式来解决，又或者通过反射来简化代码。
大伙不妨试一试？
总结
先说说策略的优缺点：
策略模式的优点就在于可以灵活的选择需要使用的算法，减少ifelse语句；
缺点就是，如果具体的策略类较多的话，各个策略类之间不具有复用性。
具体的应用场景呢？
需要进行算法切换的场景，且各个算法之间只有实现上的差异，其余参数可以抽离出来共用。
参考链接
《大话设计模式》
《Head First 设计模式》
https://www.cnblogs.com/adamjwh/p/11011095.html
项目地址
https://github.com/white0dew/Design-pattern/tree/master