1700458800
1700458801
1700458802
设计模式之禅 10.3.2 模板方法模式的缺点
1700458803
1700458804
按照我们的设计习惯，抽象类负责声明最抽象、最一般的事物属性和方法，实现类完成具体的事物属性和方法。但是模板方法模式却颠倒了，抽象类定义了部分抽象方法，由子类实现，子类执行的结果影响了父类的结果，也就是子类对父类产生了影响，这在复杂的项目中，会带来代码阅读的难度，而且也会让新手产生不适感。
1700458805
1700458806
1700458807
1700458808
1700458809
设计模式之禅 10.3.3 模板方法模式的使用场景
1700458810
1700458811
❑多个子类有公有的方法，并且逻辑基本相同时。
1700458812
1700458813
❑重要、复杂的算法，可以把核心算法设计为模板方法，周边的相关细节功能则由各个子类实现。
1700458814
1700458815
❑重构时，模板方法模式是一个经常使用的模式，把相同的代码抽取到父类中，然后通过钩子函数（见“模板方法模式的扩展”）约束其行为。
1700458816
1700458817
1700458818
1700458819
1700458820
设计模式之禅 [:1700453953]
1700458821
设计模式之禅 10.4 模板方法模式的扩展
1700458822
1700458823
到目前为止，这两个模型都稳定地运行，突然有一天，老大急匆匆地找到了我：
1700458824
1700458825
“看你怎么设计的，车子一启动，喇叭就狂响，吵死人了！客户提出H1型号的悍马喇叭想让它响就响，H2型号的喇叭不要有声音，赶快修改一下。”
1700458826
1700458827
自己惹的祸，就要想办法解决它，稍稍思考一下，解决办法有了，先画出类图，如图10-4所示。
1700458828
1700458829
1700458830
1700458831
1700458832
图10-4 扩展悍马车模类图
1700458833
1700458834
类图改动似乎很小，在抽象类HummerModel中增加了一个实现方法isAlarm，确定各个型号的悍马是否需要声音，由各个实现类覆写该方法，同时其他的基本方法由于不需要对外提供访问，因此也设计为protected类型。其源代码如代码清单10-9所示。
1700458835
1700458836
代码清单10-9 扩展后的抽象模板类
1700458837
1700458838
public abstract class HummerModel{
1700458839
1700458840
/*
1700458841
1700458842
*首先，这个模型要能够被发动起来，别管是手摇发动，还是电力发动，反正
1700458843
1700458844
*是要能够发动起来，那这个实现要在实现类里了
1700458845
1700458846
*/
1700458847
1700458848
protected abstract void start（）；
1700458849