将公用的方法放在父类组合,确定顺序,然后实现交给子类
结合策略模式使用场景:
有不同的优惠券策略,然后每种策略在实现的时候,走的是统一的一套逻辑流程,但又有某些策略的流程不太一样,有一点小特殊流程
此时,每种策略的实现就可以用模板方法模式,抽象出公共的顺序
如果不用模板方法,代码将是这样的
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的方式,在每个策略中还是得再写一行公用的方法调用~