读《漫谈设计模式》

和《代码大全》差不多厚就可以了，实在不行可以分卷，第一卷，第二卷……第六卷，我估计不会出到第八卷。

我记得，一位大牛曾经说过一个故事说：
有人向他写信，说他把GoF的22个模式都在系统使用了，就剩下一个解释器模式没有使用，他实在没有办法找出来可以使用的地方。
我们要使用，只是它合适解决问题，还要变化它们（因为你的问题和它提到问题总是有出入的），来调整以解决自己的问题，本质是面向对象（gof说的，是把有经验的开发设计者的经验告诉大家），因为，你懂面向对象的话，就不用知道这些模式，你也会遇到相同的问题，找到你的解决方案，而这个解决方案，和23个被有经验的设计者归纳出来的应该是一样的。

声明：本人既非阎宏本人也非最熟悉的人 而是他的书的受益者
redhat说我不懂设计模式，那我就以局外人的身份浅略谈一下看法：
要想要把设计模式解释清楚，首先应该向人家解释清楚某种模式适用的场景、内部有哪些组件构成以及各自的责任，模式中的组件本身不是自调用的，所以还要把调用者的责任解释清楚，以及将来需求发生变化时我们所采用的模式是如何降低需求对代码产生的影响的。我记得在阎宏的《Java与模式》中没各章节还谈到了正在介绍的模式与其它模式之间的区别和联系，这些都很能帮助我们在实际场景中选择合适的模式。

不成熟的看法：不把模式放到大的场景中去讨论是没有意义的，有道是不谋全局者不足以谋一域，而贵书对设计模式的讨论仍还在一域的境界，《Java与模式》中则含大局观。

声明：本人既非阎宏本人也非最熟悉的人 而是他的书的受益者
redhat说我不懂设计模式，那我就以局外人的身份浅略谈一下看法：
要想要把设计模式解释清楚，首先应该向人家解释清楚某种模式适用的场景、内部有哪些组件构成以及各自的责任，模式中的组件本身不是自调用的，所以还要把调用者的责任解释清楚，以及将来需求发生变化时我们所采用的模式是如何降低需求对代码产生的影响的。我记得在阎宏的《Java与模式》中没各章节还谈到了正在介绍的模式与其它模式之间的区别和联系，这些都很能帮助我们在实际场景中选择合适的模式。

不成熟的看法：不把模式放到大的场景中去讨论是没有意义的，有道是不谋全局者不足以谋一域，而贵书对设计模式的讨论仍还在一域的境界，《Java与模式》中则含大局观。

终于不是吵架了哈，

不明白，小的场景为什么不能使用，只有大的场景才可以使用，讨论才有意义，我觉得GoF的任何一个模式都不是大的场景，至于场景，组件（对象），即各自的责任，没有介绍怎么讲模式？突然冒昧问一句，怎么体现那些组件和各自的职责？组件和对象的关系，职责和封装的方法的关系，您弄清楚了吗？

设计模式不是写了书了才有权利说懂的，以您的“从回家过年说起”为例，个人觉得这个例子并不足以体现模板模式的好处，这里你仅考虑到了乘坐不同的交通方式，但是考虑再复杂一点，即使是乘坐大巴，可能有的人去丽泽桥、有的人去赵公口...（以北京为例），现在的实际情况是买票也要去车站买（长途汽车暂不支持网络购票），那用你的思路要写很多个子类吧。假设万一哪天有了个公共订票平台（可以定火车票和长途汽车票），您所有子类的订票方法是不是要重写呢？？

其实大可不必整的这么高深，组合模式大多数人都熟悉，把订票定义成一个接口OrderTicket然后让您的HappyPeople项下面这样：
pubclic class HappyPeople{
  public void celebrateSpringFestival(OrderTicket ot){
    ot.orderTicket();//订票逻辑
    ......//其它逻辑
  }
}
我觉得在这个场景中“乘车”和“与家人团聚”也可仿照“订票”被抽象成接口，因为有的人与家人团聚就是吃饺子、而有的人看电影、有的人....总之情况很多很多。这样改造后就可以实现每个HappuyPeople有各自的订票方式、各自的乘车方式、各自与家人团聚的方式、而订票、乘车、与家人团聚的具体实现也能得到最大程度的复用。

综上，你以这个场景介绍模板方法个人认为太牵强。

为了用模式而用模式，并不利于问题的解决，其实我上面仅仅用了OO！！！！！！

早说了   例子就那么几个

为了避免直接抄例子   人家说是法拉利   他用土话 说个拖拉机

我是来讨论问题的 不是和你们骂阵的

正解...

我说的大场景是指模式内部组件之外的场景。

很显然，“从回家过年说起”中HappyPeople的订票、乘车、与家人团聚是整体业务逻辑与局部业务逻辑之间的关系，您觉得用模板方法比用组合更合适吗？

如果您实在不理解模板方法的精髓，建议你好好想想Servlet是怎么回事，这是模板方法的经典用法。