1700458783
设计模式之禅 10.3 模板方法模式的应用
1700458784
1700458785
10.3.1 模板方法模式的优点
1700458786
1700458787
❑封装不变部分,扩展可变部分
1700458788
1700458789
把认为是不变部分的算法封装到父类实现,而可变部分的则可以通过继承来继续扩展。在悍马模型例子中,是不是就非常容易扩展?例如增加一个H3型号的悍马模型,很容易呀,增加一个子类,实现父类的基本方法就可以了。
1700458790
1700458791
❑提取公共部分代码,便于维护
1700458792
1700458793
我们例子中刚刚走过的弯路就是最好的证明,如果我们不抽取到父类中,任由这种散乱的代码发生,想想后果是什么样子?维护人员为了修正一个缺陷,需要到处查找类似的代码!
1700458794
1700458795
❑行为由父类控制,子类实现
1700458796
1700458797
基本方法是由子类实现的,因此子类可以通过扩展的方式增加相应的功能,符合开闭原则。
1700458798
1700458799
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
1700458821
设计模式之禅 10.4 模板方法模式的扩展
1700458822
1700458823
到目前为止,这两个模型都稳定地运行,突然有一天,老大急匆匆地找到了我:
1700458824
1700458825
“看你怎么设计的,车子一启动,喇叭就狂响,吵死人了!客户提出H1型号的悍马喇叭想让它响就响,H2型号的喇叭不要有声音,赶快修改一下。”
1700458826
1700458827
自己惹的祸,就要想办法解决它,稍稍思考一下,解决办法有了,先画出类图,如图10-4所示。
1700458828
1700458829
1700458830
1700458831
[
上一页 ]
[ :1.700458782e+09 ]
[
下一页 ]