美津植秀的水怎么样:跪求！老版的step by step 2的 文本

Design.Patterns.Step.By.Step.2
Template Method使用了对象继承，而继承是一种很强的对象和对象之间的耦合关系，底层模块还是依赖于高层模块，比如子类要知道哪些abstract method要重写，哪些hook method可以做扩展，哪些基类资源可以利用。

strategy模式使用对象之间的组合关系来代替继承，进一步减弱高层模块和底层模块之间的依赖，让底层独立于高层，使其完全符合更符合DIP的原则, 这样底层代码不需要了解高层代码是怎么工作的，高层也不需要知道底层的实现细节，

相对于Template Method模式来说strategy模式革命的更彻底一些。

还拿Report来作一个简单的例子。

Report的输出可以是Html格式的，可以是Word格式的，也可以是PDF格式的，我们可以定义一个Interface:IReportPublisher，在IReportPublisher中定义高层模块和低层模块之间的调用协议。（或者说Contract）

Interface IReportPublisher {public void Publish()}

HTMLReportPublisher : IReportPublisher

WordReportPublisher : IReportPublisher

PDFReportPublisher : IReportPublisher

Report

{

Public void GenerateReport()

{

…

reportPublisher = MyContext.GetService(…)

reportPublisher.Publish(reportData)

…

}

}

当然实现strategy模式也有代价，将Template Method改造成strategy模式后，架构中层次变复杂了，一些Template Method模式原有的特性就没有办法利用了，比如子类可以调用基类一些资源。

应用任何一种模式都会有代价，学习模式时，明白为什么这么做比明白怎么实现更重要，了解模式带来的收益的同时也要了解你要付出的代价。模式也是一直随着技术的发展在发展的，有些模式在慢慢消亡，有些新的模式出现，有些模式被新的编程语言天然支持，有些模式的形式发生了变化，Gof的《设计模式》里的一些观点现在来说已经是有些过时了。

strategy模式和Template Method模式的对比还体现了面向对象的另一个思想，解决对象之间的协作问题应用对象组合优先于对象继承。在面向对象的初期，人们非常看重对象继承，继承一个类，就可以重用该类的代码，把很多类的代码抽取到一个基类中就可以去掉代码重复，创建一个子类，改变一点点就能创造出一个能实现新功能的类出来，通过继承我们可以建立完整的软件结构分类，每一层都可以重用该层以上的代码，这看起来很美好，到后来人们才慢慢发现继承非常容易被过度使用，而过度使用带来的收益比代价要高的多，所以我们减少对继承的使用，用组合和委托来代替继承。

strategy模式和Template Method模式都面对一个问题，在运行时怎么创建某个子类或者某个实现了某个interface的类的实例，那就涉及关于创建对象实例的模式：Singleton模式和Factory模式。

http://www.mambochina.net/content/view/15_38.html

看看吧,也许对你有所帮助.

我这里有一本，不知是否？华东师范大学出版社出版。