论： 设计模式是不是每天要用？
对于“设计模式是不是每天要用？”这个问题，我的看法是，能用就用。
在我看来，模式的主要服务对象不是设计，而是交流。
这一点我记得GoF模式书是有说过，但不是很强调。
而各种模式书的模式表述法为： 提出问题，然后用模式解决。
结果许多设计者就把自己的问题与之对照，然后套用对应模式解决问题。
包括我自己，以前也是这样做的。模式成为了设计的工具。
其实，最初的模式产生于设计之后，相类似的解决方案总结才产生了模式。
如果没有模式的概念，你同样能作出问题的解决方案。
模式最有用的地方应该是交流。
表达一个设计最简洁的方法就是用一个或几个模式概要之。
如对一个系统你这样描述：它是一个管道模式系统，
数据以文件方式进入后，经过A，B，C处理，最终流入D。
前提是交流的各方都要对模式有所熟悉。
程序员A：报表这块怎么设计？
架构师：用一个Possibility模式。
程序员A：请问什么是Possibility模式？
架构师就必须解释什么是Possibility模式。
在对模式的理解上达成一致的情况下，才能有效利用模式进行交流。
在传统的设计中，模式大概是很有用的，它提供了灵活的设计，把可变性提出另一层次进行处理。
而在现在流行的灵巧式开发中，设计与代码交替进行，模式对于设计的帮助就大大减小了。
因为设计处于不断的演化中，不是先定模式再有设计，而是先有了设计，再看到模式。
模式不是作为设计的指导，而成为设计演化的结果。
你在一次设计重构之后大呼：“现在我们已经进化到MVC模式了！”，而不是一开始就决定要应用MVC。
有了模式，你可能会觉得套用模式会使设计变得简单，而且“专业”。
在有些情况下，我觉得还是摈弃模式才会有简单的设计。
我有过多次经验，将原有的模式通过重构，进行简化，去除不必要的类层次，
结果是仅用简单的继承或组合就能解决问题。
仔细一看，模式是可以退化成更简单的形式的。
例如，你不需要单件模式，一个类只实例化一次就可成为一个单件。
对于熟悉的人来说，应用模式简化了设计，对于不熟悉的人来说，模式反而使设计更能理解。
还有一个问题是，GoF的模式书和其它模式书中仅对有一定复杂性的模式作了列举，因为复杂才能显示其水平。
而实际应用中，更有用的是书上未列举的模式，或退化的模式。
如简单的继承，单一单向的组合，这些都是有用又好用的模式。
如MVC这类较大型的模式，应该是由框架提供，自己对实现的机会不多。
即使你没用框架，也可以不用MVC，同样能实现数据展示功能。
简单的模式可以逐步演化为复杂的模式。
原文 转自： 设计模式是不是每天要用？
每天必用设计模式的公司：
第一天
程序员A：报表这块怎么设计？
架构师：用一个Possibility模式。
程序员A：请问什么是Possibility模式？
第二天
项目经理：昨天讨论了，报表这块怎么设计？
程序员A：用一个Possibility模式。
项目经理：请问什么是Possibility模式？
第三天
程序员B（新来的）：请问报表这块怎么设计？
项目经理：用一个Possibility模式。
程序员B：请问什么是Possibility模式？
问题：
* 刚毕业的大学生没学过模式，还有好多人不熟悉。如果都要懂，会不会累死人？
* 设计模式不只GoF的23个，其他人也总结了N多个。那么多的模式，你懂的我不一定懂，我懂的你不一定懂，怎么交流？
* 今天流行这个模式，明天那个模式消亡，我们是为了模式而生存吗？
* 大师们都懂模式吗？他们会不会因为不懂模式而干不了活，丢掉饭碗？Bjarne Strustroup, Stan Lippman, Danny Thorpe, Brian Kernighan, Peter Coad, Knuth, Andrei Alexandrescu, Steve McConnell, Herb Sutter, Anders Hejlsberg, Dennis Ritchie, ...
建议：
* 学校中开设设计模式课，但类似于数据结构，只教授经过历史洗礼、非常经典的模式；
* 将模式提交给标准组织，产生标准模式。学校里只教授标准模式。
* 同样，交流时应只以标准模式为术语，非标准模式仅限于相互熟识的局部。就如：说话要说普通话。否则就象缩写词一样，大家云里雾里，不知所云。
