不用模式的理由

周日去找sunway看他的半冰箱胶卷及扫描仪，一起吃完晚饭出来时，我想起reallike说过的一句话：不要跟sunway谈模式。于是趁机challenge了一下，结果还是比较有收获的。

关 于模式的问题我曾经跟令狐有过多次的讨论。sunway并不能算是一个严格的模式反对者，他只是反对在自己项目中采用模式。为此他举了很多的例子，基本上 我还是比较认可的。例子我就不一一列举了，有过一定的编程实践经验的人多少都会碰到类似的问题，但意识到的人并不多，我作一下大致的总结：

问 题主要表现在几个方面。

一方面是对于模式的初学者来说，很容易陷入为了模式而模式的误区。这里所指的初学者与学习设计模式的时间长短无关，而在于对设计模 式的理解上，仅仅是把所有的模式背下来是远远不够的。用我不厚道的话来说就是：“这只是一本人肉Reference”。

另一方面是这种对模式的“硬用”实 际上是低效的，因为很多时候你对某个模式的“硬用”根本就是错误的，结果必然导致在实现这一错误的“硬用”上花费很多不必要的时间，影响开发效率。

还有一 方面就是一个人对模式的“硬用”错误，在团队中开始可能还不被发觉（因为只要能用，这种潜在的问题通常是不容易发现的），随着项目的不断修改，可能到很后面才发现这里的“硬用”有问题，再来修改的代价就会很大。

最后 一 方面是在团队开发中，各人的理解各不相同，也许一个人认为应该在这里要用A模式，但另一个人却认为应该用B模式，或者一个人“硬用”的模式对另一个人理解 代码造成了不必要的障碍。

诸如此类都是sunway拒绝在项目中使用模式的合理理由，对此我基本上表示赞同。

模式的起源与其它计算机理论有 很大的不同，它源于建筑设计大师Christoph.Alexander的模式思想——甚至可以说是一种哲学思想，它与一般意义上的西方哲学有很大的不 同，而是接近于东方的古老哲学思想。在这一哲学思想中，有一个核心形容词叫做“生机勃勃”。当年GoF就是受到这一哲学思想的影响，从大量的实践经验中总 结出来设计模式的想法——他们发现在一些看上去“生机勃勃”的代码中，存在着一些共性的东西，他们对这些共性的东西加以总结，得出我们现在所知道的设计模 式。

C.Alexander在《建筑的永恒之道》一书里谈论到建筑模式语言时就说到过，同样的模式用在不同的地方，会有不同的效果，必须结合很多的方面综合考虑，唯一的原则就是要使最终的建筑具有那种生机勃勃的无名特质。

所 以，光会背模式和堆砌模式完全没有意义，因为这样的模式是“死”的，而不会是生机勃勃的。要会用好设计模式不是看几本书就能明白的，你需要在不用模式的情 况下编写大量的代码，慢慢地去体会那种对“生机勃勃”的感觉——当然你也可以说我这是经验主义，但对于编程这种事情来说，经验就是很重要的。

回 到sunway的话题上。他作为一名leader，重要的是能够让整个team高效地运作，而要达到这个目标，合理的投入产出分析是必要的。因为几乎不可 能要求整个team的所有成员都有足够丰富的经验去正确地运用模式，并且不会给别的成员带来误解，所以在他的team他的项目中使用模式带来的成本过于 高，那么不用当然比用要好。

对此，令狐也有一些相关的评论（我编辑整理过）：

因为模式这个东西，不仅仅是 一个名字，还会跟环境、跟语言，跟很多东西相关。设计模式在设计时是可以作为一个名词交流的。但在实际编码的时候，绝大多数情况不会像书上的例子那样单 纯，是需要根据情况实际调整的（或者）根据需求，写出一些代码，这些代码事后可以发现跟某种模式相符。
另外还有一点，就是设计模式使用不当，很容易产生“过度设计”的问题，但是现在又没有一个有效的模式可以防止过度使用模式。
最 近看了一点《建筑的永恒之道》，总的感觉，我觉得它提到的模式，更像是一种东方文化和西方文化的杂交产物，是一种无法精确定量的东西。虽然它提到说模式必 须可以明确的表达出来。但是模式受到周围很多环境和事件的影响，很难用一个绝对教条的方法去归纳和实施。从一方面来说，模式本身可以精确定义和重现，这个 是很典型的西方哲学方法。但是，模式的应用，却受到很多外界条件的影响，甚至是一些难以描述的神秘状态的影响，同一个模式，在这个条件下应用，是合适的， 是好的，在另一个环境下，可能就变成了一个不好的，不合适的，这个又很东方化。

的确是这样，模式本身是明确的，但是应用模式的环境（包括软硬件环境和人的环境）却是千变万化的，没有经验和对“生机勃勃”的感觉是很难用好的。

也许对于小团队，一次性的项目来说，模式的“硬用”可能影响还小一些，或者会有一些好处，但是对于大团队，常变化的项目来说，为了避免模式“硬用”而完全禁用模式也不失为一种有效的管理方法。

总之我认为，模式绝对是个好东西，但不是绝对的好东西。