（五）模板方法模式

将公用的方法放在父类组合，确定顺序，然后实现交给子类

结合策略模式使用场景：
有不同的优惠券策略，然后每种策略在实现的时候，走的是统一的一套逻辑流程，但又有某些策略的流程不太一样，有一点小特殊流程
此时，每种策略的实现就可以用模板方法模式，抽象出公共的顺序

如果不用模板方法，代码将是这样的

public class StrategyA{
	public void calculate() {
		System.out.println("通用的计算逻辑");
		System.out.println("A的特殊逻辑");
	}
}
public class StrategyB{
	public void calculate() {
		System.out.println("通用的计算逻辑");
		System.out.println("B的特殊逻辑");
	}
}
public class StrategyC{
	public void calculate() {
		System.out.println("通用的计算逻辑");
		System.out.println("C的特殊逻辑");
	}
}

这里有个明显的问题就是，每个策略中，都有相同的一段，通用的计算逻辑，这个逻辑通过复制粘贴，复制了三份。。。。
开发起来是图省事了，但是这段逻辑一旦要修改，所有的策略都得改。。。。
到了大后期，没人知道这种代码都藏在哪里，要一点一点排查，然后生产验证一遍一遍改，这就是垃圾代码！

下面开始改造：
首先定义接口和抽象实现类，目的是封装整个计算的逻辑顺序

public interface Calculator {
	void calculate();
}
public abstract class AbstractCalculator implements Calculator {
	@Overide
	public void calculate() {
		commonCalculate();
		specificCalculate();
	}
	private void commonCalculate() {
		System.out.println("通用的计算逻辑");
	}
	protected abstract void specificCalculate();
}

现在再改我们的策略

public class StrategyA extends AbstractCalculator {
	public void specificCalculate() {
		System.out.println("A的特殊逻辑");
	}
}
public class StrategyB extends AbstractCalculator {
	public void specificCalculate() {
		System.out.println("B的特殊逻辑");
	}
}
public class StrategyC extends AbstractCalculator {
	public void specificCalculate() {
		System.out.println("C的特殊逻辑");
	}
}

可能有人说，这没什么稀奇的，其思想只不过是将公用的方法提出来了
但仔细看一下可以发现，模板不仅将公用方法提出来了，而且只写了一遍
而在业务代码中，提出公用代码到一个service的方式，在每个策略中还是得再写一行公用的方法调用~