不用模式的理由

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

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

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

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

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

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

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

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

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

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

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

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

对此,令狐也有一些相关的评论(我编辑整理过):

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

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

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

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