论：设计模式是不是每天要用

论： 设计模式是不是每天要用？

对于“设计模式是不是每天要用？”这个问题，我的看法是，能用就用。

在我看来，模式的主要服务对象不是设计，而是交流。
这一点我记得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, ...

建议：
* 学校中开设设计模式课，但类似于数据结构，只教授经过历史洗礼、非常经典的模式；
* 将模式提交给标准组织，产生标准模式。学校里只教授标准模式。
* 同样，交流时应只以标准模式为术语，非标准模式仅限于相互熟识的局部。就如：说话要说普通话。否则就象缩写词一样，大家云里雾里，不知所云。