设计模式之模板模式
《Java与模式》实在太厚重了，曾经看了又看，忘了又忘，昨晚闲来无事，想假装认真读书，做个上进的青年，就随意翻了这本书。这一看，竟让我发觉自己有意无意地使用了模板模式。公司的框架大大方便了我们写程序，却又让人觉得索然无味，什么都被固定，唯一要做的就是往里面填代码，郁闷死了。
我没有说那就是模板模式。但模板模式就差不多这样，规定了第一个步骤做什么，具体怎么做就交给你，你就只能这么做。做软件的最高境界就是这样了，设计师一旦设计好，程序员就变成打字员。面对这么无聊的coding，我只好在用自己的手机号作串行序列号，用金莎在歌名作打印机JobID，用工大后院网址作彩蛋.......
《Java与模式》这本书讲到，HttpServlet这个类在service方法调用doGet,doPost等方法，子类只要根据需要去具体实现doGet之类的方法即可。这就是模板模式。如果你有兴趣又有空，可以去查查源码。
我无意用到这个模式是在写一个客户端程序时，因为要打开文件，对文件进行导入，然后又要作相应处理。一开始就按部就班地写，突然觉得不方便，就把一个方法分成beforeImport,importFile,afterImport三个方法。这样把一个方法分成三个方法，无非是把代码拷贝一下而已。示意代码如下：
abstract boolean beforeImport()
abstract boolean importFile()
abstract boolean afterImport()
final void _import(){
if(beforeImport()){
do something...
if(importFile()){
do something...
afterImport();
}
}
}
_import定义成final是为了不让子类改写，当然，应该根据具体情况决定要不要这样做。
这样一时看不出有什么好处。后来，因为要增加一种不同的文件来源，即刚好可以省略beforeImport方法，而只调用importFile和afterImport。
其实当时这样写也没有得到什么太大的好处，只觉得好玩而已。不久后做另外一个程序，需要对外暴露很多接口方法，而方法的参数都是同一抽象类型。这样，继续使用模板模式，在抽象类写一个模板方法，同时让抽象类担当门面模式的角色，这样就可以在每个要暴露的接口方法复制同样代码了。如：
AbstractTask.doSomething(value);
这样搭建好后就可以把具体工作交给别人做了，分配大家一人写一个具体类多好啊！可惜我这只是我的幻想，全部类最终还是我写了。
综上所述，模板模式有点呆板。
用自己的手机号作串行序列号，用金莎在歌名作打印机JobID，用工大后院网址作彩蛋
016
模式.. 跳槽吧～ 师兄收留我？ 收留条毛～～～学你个同事甘跳拉～～～
页:
[1]