[b]前言[/b] 离开了自己工作了将近两年的公司，日子不再有了忙碌，可以闲下来，躺在家里的床上，想着以后的路怎么走，说实话，真的很迷茫，从2012年毕业到现在，时间不长，但是学到的东西真的是非常有限，一直从事于Windows平台上的开发。说到Windows平台的开发，大家都肯定知道的HOOK的，即使不知道HOOK，对于COM应该也是知道的，我的系列博文中也对COM进行过全面的总结。说白了，HOOK就是在执行某个功能时，会有一个一系列的执行过程，对于这个过程一般都是固定的，比如：第一步执行什么，第二步干什么，最后一步干什么，都是设计好的。而具体如何去完成每一步，都是可以由程序员去控制的。COM也是如此，COM是面对接口的，当完成某一个功能模块时，就可能是系列接口的叠加调用，而接口的实现都是由程序员来控制的。说白了，一个功能模块的实现流程是固定了，但是对于每一步的具体实现都是不固定的。对于这种需求，一般是如何来做的呢？从设计模式的角度来说，这个设计模式叫模板方法模式，可能你不知道这个设计模式的名字，但是，这种方法你已经用过了。现在我就对模板方法模式进行详细的总结。 [b]模板方法模式[/b] 在GOF的《设计模式:可复用面向对象软件的基础》一书中对模板方法模式是这样说的：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。TemplateMethod使得子类可以不改变一个算法的接口即可重定义改算法的某些特定步骤。 我结合我在实际开发项目中的一个例子来说说这个模板方法模式吧。我们曾经做过一款产品，这个产品类似于一个云端的文件管理客户端。对于这样的一个客户端，由于其云端的服务器有三种，而每一种服务器之间的通信方式和对外公开的接口都是不是一致的，这就需要实现的客户端要屏蔽云端服务器和接口的差异性，而提供统一的操作界面，所以在实现这个客户端的同时，我们实现了一个框架，一个对于服务器和接口是通用的框架，比如就拿文件下载来说说。我们的实现大概如下: 下载文件的流程为：先调用DoBeginDownloadFile，执行下载文件之前的一些操作，再调用DoDownloadFile实现真正的文件下载，最后调用DoEndDownloadFile完成文件下载的清理工作。对于任何服务器，下载文件的这个流程是不会发生变化的。而在DoBeginDownloadFile、DoDownloadFile和DoEndDownloadFile的内部具体是如何实现的，由程序员根据具体的云端服务器和对外公开的接口来完成的。最终客户端去完成文件下载操作时，只会调用DownloadFile函数就可以完成。可以看到，在上面的代码中，只有DownloadFile是public的，其它的操作函数都是protected。这也意味着，我们完成的框架对外只公开DownloadFile接口。 [b]UML类图[/b] [img]http://files.jb51.net/file_images/article/201410/201410995307339.png?20149995321[/img] AbstractClass（抽象类）：定义抽象的原语操作，具体的子类将重定义它们以实现一个算法的各步骤。主要是实现一个模板方法，定义一个算法的骨架。该模板方法不仅调用原语操作，也调用定义在AbstractClass或其他对象中的操作。 ConcreteClass（具体类）：实现原语操作以完成算法中与特定子类相关的步骤。 由于在具体的子类ConcreteClass中重定义了实现一个算法的各步骤，而对于不变的算法流程则在AbstractClass的TemplateMethod中完成。 [b]使用场合[/b] 模板方法是一种代码复用的基本技术。它们在类库中尤为重要，它们提取了类库中的公共行为。在使用模板方法时，很重要的一点是模板方法应该指明哪些操作是可以被重定义的，以及哪些是必须被重定义的。要有效的重用一个抽象类，子类编写者必须明确了解哪些操作是设计为有待重定义的。 [b]代码实现[/b] 这里就根据上面的类图，对模板方法模式进行了简单的实现。由于该模式非常简单，所以也没有更多的可以讲的了。 [b]总结[/b] 模板方法模式，总的来说很好接受，很好理解，没有难点；对于此设计模式，我个人觉的还是可以和装饰模式进行对比一下。还是有一些相似之处的。好了，该设计模式的讲解就到此结束。