模板方法模式策略模式 的 联系区别和应用场景

Posted 2020-06-14

介绍和实现：

1. 策略模式的结构其实非常简单，比模板方法模式简单多了，它实质上就是一个原则的体现，往低里说就是里式替换原则，往高里说是依赖倒置原则，具体实现过程是这样：
   1. 有一个接口（抽象类）A中有一个抽象算法方法a
   2. 有一组接口（抽象类）A的实现类（子类）A-? 用不同具体算法实现了抽象算法方法a
   3. 然后有一个业务类B中有业务方法b和类型为A的对象成员c，其中方法b中通过调用c的算法方法a来干一些活
   4. 最后在使用时，实例化业务类B时传入不同的A的子类A-？以实例化出使用不同算法的业务类B的对象
2. 而模板方法模式
   1. 有一个抽象类A中有两个方法（暂时忽略钩子方法），抽象算法方法a-abstruct，模板业务方法a-mode（模板方法中使用到了抽象算法方法，所以其实这个模板方法现在还不能正常工作）
   2. 然后接着写一组子类A-？继承抽象类A，在子类中用不同算法实现了抽象算法方法a（模板方法能正常工作了）
   3. 最后在使用时，直接实例化不同的子类A-？以实例化出使用不同算法的对象，调用对象的模板方法就可以进行业务

共同点：

1. 目的是一样的，让不同算法实现的业务复用代码

区别：

1. 形式看起来就是【策略模式】把【模板方法模式】中的模板方法独立到另一个类中，然后在使用的时候，再跟实现了的算法子类拼接到一起。（使用的时候拼接，用户能知道自己在使用什么模式）
2. 【模板方法模式】在使用的时候，不用拼接，因为在继承的时候已经是分开继承的，两个方法本来就在一起，你要用哪组就直接调用哪组就行了。（用的时候直接调用完整方法，用户不知道是什么模式实现的）

一个混淆：

1. 有时候策略模式中，实现类A-？中用不同具体算法实现的抽象算法方法a中可能有很多重复代码，这个时候为了复用，就把这些重复代码剥离出去，用的时候再调用，那剥离到哪儿呢，就剥离到接口A中，那这个时候接口A就必须是抽象类A了，在这个时候你会发现，策略模式的抽象类A中也有两个方法，也是一个抽象算法方法和另一个具体方法，看着是不是有点像模板方法模式，但其实完全不同：
   1. 这里的具体方法并不是模板方法，而是另一个工具方法
   2. 另外还是有一个业务类B和业务方法b，这个b才是意义上的模板方法
2. 表面上看策略模式复杂，其实不然，策略模式就是最最简单的面向接口编程的一个例子，最最简单的多态的一个体现，从这个角度看，其实是非常简单的

优缺点或者说两个方法的适应场景：

1. 看了很多，发现很多偏颇或者说一团浆糊的理解，即使是已经工作的程序员，所以我特地辩驳一下
   1. 大部分人倾向于两者差不多，懒得吐槽了
   2. 还有人甚至对两种模式的界定都分不清，用不要拘泥于模式来搪塞，然后最后说创新了一种介于两者之间的模式，其实就是这两种中的一种，比较多的其实是使用了抽象类代替接口的策略模式
   3. “它们都像试卷，模板模式是填空题，策略模式是选择题”，混淆了开发阶段，在创建阶段时，两者都是填空题，在使用阶段时，两者都是选择题
   4. 然后还有人认为两者最大的区别是外界对方法修改的访问权限的区别，这个不能说没有，但是这个点几无价值
2. 个人体会
   1. 模板方法适合小项目，因为它的形式最简单，用起来方便，但是它对算法的复用比较不灵活，而且大量的继承会产生大量冗余代码，也加重了系统负担
   2. 策略模式适合大项目，它形式虽然复杂一些，但是管理规范，对算法的复用也可以非常灵活（尤其是在使用抽象类代替接口时），甚至可以用多重算法嵌套来进一步减少冗余代码，而且由采用类的组合，冗余代码也能减少很多