模板模式和策略模式的区别

转载：http://bhsc.happy.blog.163.com/blog/static/104389552200811178630564/

 

 

要感谢这篇文章带来的灵感：对Strategy与Template Method模式的区别的一些讨论，有些地方说，strategy 使用接口.template  使用抽象类,抽象类中包含了一些具体的步骤........................晕，傻子才看不出来一个是接口，一个是抽象类，可是这真的是本质区别嘛？或者说这个区别够深入吗？

    我研究了好久，发现这两个模式很可能就体现在这个一组算法，还是一个算法上，但是始终理不太清楚，现在终于明白。记录一些关键的东西吧：

 

根据《深入浅出设计模式(C#/Java版)》所述,

Strategy模式的应用场景是:
1. 多个类的分别只是在于行为不同
2. 你需要对行为的算法做很多变动
3. 客户不知道算法要使用的数据

 

Template Method模式的应用场景是:
1. 你想将相同的算法放在一个类中,将算法变化的部分放在子类中实现
2. 子类公共的算法应该放在一个公共的类中,避免代码重复

 

仔细体会作者所提出的这几个应用场景,你会发现它们其实没什么区别,用Strategy或Template Method模式都能完成要求.换句话说,作者没抓住这两个模式区别的"痛处"来给予详细讲解.下面我们再换个出发点来看看这两种设计模式.

 

我们知道,设计模式中有这么一个原则: Prefer composition to inheritance.这句话的背景是OO初期大家都把继承看作是万能的,并过度使用继承来实现多态->可扩展.理解原则的时候不能脱离它的背景,不然就成盲从了.Template Method模式应该是伴随着OO的出现而萌生的.它是OO中最直观的思考方式的结果.基类留下可变化的空间给子类,由继承类来决定具体行为.听起来是不错,不过...一旦基类的接口发生了变化,每个继承类都得跟着修改才能够继续使用.这就是所谓高耦合与难维护的说法的来源.

 

Strategy与Template Method模式算是composition与inheritance的典型应用了,如果它们真的在功能上能完全互换,那何必要后者呢,全部都用前者不是很好么? 再怎么说,一个倾向于加深类层次结构的设计通常会使设计变得复杂,令后期维护变得困难.

When deciding between inheritance and composition, ask if you need to upcast to the base type. If not, prefer composition (member objects) to inheritance. This can eliminate the perceived need for multiple base types.

Which should I prefer: composition or private inheritance? Use composition when you can, private inheritance when you have to.

有一个说法总结得不错: 到底该倾向于composition还是inheritance,决定于"变化的是什么".如果基类的接口变化得很频繁,那么使用inheritance绝对是个噩梦;如果只是给基类新增方法,那么坚持使用composition的话就得新增很多个delegate.

这么说来,Strategy与Template Method模式之间的区别,也是在"变化的是什么"这个问题上了.

 

注意到,Strategy模式中,为了让Context类能够调用,Strategy接口里声明的方法一般是公有的.Template Method模式则不然,基类中留下的虚方法并不一定要是公有的,只要保证对继承类可见就行.也就是说,Template Method模式允许编写库的人采取更紧的访问限制,而Strategy模式则很难做到相同等级的限制.假如使用者获得了一个Strategy接口的实现类的实例,他并不一定要将这个实例放入"原本应有"的那个Context,而可以随意使用其中的接口方法.Template Method模式可以利用protected的访问权限,牺牲一点面向对象的封装性,给自己的继承类一定的访问特权,来把一些访问限制在"体系内",从而限制了外部对内的访问.这仍然只是表象,不过我们已经接近问题的本质了.

 

这带来的区别是什么呢? Strategy模式允许外界使用其接口方法,因而可以将这个接口方法认为是"一整个算法";而Template Method模式可以限制所留下的虚方法只对其继承类可见,外部使用者不一定能够直接使用这些虚方法,因而可以将这些虚方法认为是"一个算法的一部分".GoF的设计模式那本书里有这么一句话:"Template methods use inheritance to vary part of an algorithm. Strategies use delegation to vary the entire algorithm.",说的正是这个问题.回到具体问题上,如果我们要封装的算法适合于提供给用户任意使用,是"一整个算法",那么用Strategy模式较好;如果要封装的变化是一个算法中的部分(换言之,大算法的步骤是固定的),而且我们不希望用户直接使用这些方法,那么应该使用Template Method模式.就此,问题的"痛处"算是抓住了.

 

回到书中的例子.为什么使用Template Method模式比较好呢? 我觉得是因为那个format()方法并不应该被用户直接单独调用,因而用protected限制住了对它的访问.这就不适合Strategy模式了(用Strategy意味着默认用户单独去使用算法).

但是话说回来,作者提到了Singleton.要是用了Template Method,这Singleton基本上就泡汤了.但是又没有源代码看看作者到底实现出来的是什么样的,无法猜透他的想法啊.

 

为了这么一个问题,我硬是跟axx大争了一个晚上...我总是觉得Strategy跟Template Method模式在使用中没什么区别,而根据Prefer composition to inheritance原则,Strategy模式相对更合适于较多的场景.axx大则不停重复两种模式带来的访问限制不一样,但一直没能表述得让我明白.幸好axx大脾气好,不然这么争一次还真伤元气 XD