不用模式的理由

原创 2007年09月20日 14:34:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

不用模式的理由

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

不用触发器的理由

TOM说过他希望三样东西不曾存在:触发器,自治事务,WHEN OTHERS。         现在开发用的触发器都是表上的,FORM上的触发器是另一种东西,该用就用。每个触发器都是一个隐藏的存储过程。...
  • guogang83
  • guogang83
  • 2013年08月02日 09:17
  • 1793

从事产品经理的10大理由

对于处于十字路口迷茫的同学,常常可能都会有人给您建议,学这个学那个,从事这个行业那个行业的,而现在互联网时代, 产品经理想必是很多人推荐的方向,那我们为什么要做产品经理呢?仅仅是因为薪资高?下面小编就...
  • qq_32506555
  • qq_32506555
  • 2017年06月30日 22:38
  • 436

一千个不用 Null 的理由

港真,Null 貌似在哪里都是个头疼的问题,比如 Java 里让人头疼的 NullPointerException,为了避免猝不及防的空指针异常,千百年来程序猿们不得不在代码里小心翼翼的各种 if 判...
  • UFv59to8
  • UFv59to8
  • 2017年12月17日 00:00
  • 750

不能不用jpa的理由

jpa虽然在处理复杂查询的时候,非常需要学习和探索。但是,如果只用其中一部分功能,另一部分功能想办法取代它,会更累。 比如,在处理级联时,我们需要用到page自动分页处理,如果想通过原生处理...
  • petercnmei
  • petercnmei
  • 2017年02月24日 11:11
  • 165

git不得不用的理由

1. 快速 如果你每移动一下鼠标都要等待五秒,是不是很受不了?版本控制也是一样的,每一个命令多那么几秒钟,一天下来也会浪费你不少时间。Git的操作非常快速,你可以把时间用在别的更有意义的地方。 ...
  • u014369382
  • u014369382
  • 2015年07月22日 11:14
  • 309

给我加工资的几个理由

 由于上次在郭总办公室,在谈到工资的方面,没有详谈,而郭总您,第一句话,就直截了当的说:“我凭什么给你加工资!,你有什么成绩让我给你加工资!”,一句话,当时就把我搞晕过去了。我这几天细想了一下,我觉的...
  • yuezu1026
  • yuezu1026
  • 2008年09月19日 08:28
  • 6071

程序重构的理由

 以下是程序需要进行重构的理由:1. 代码重复冗余2. 冗长的子程序3. 循环过长或嵌套过深4. 内聚性太差的类5. 类的接口未能提供层次一致的抽象6. 拥有太多参数的参数列表7. 类的内部修改往往局...
  • blueheart20
  • blueheart20
  • 2007年05月09日 16:14
  • 592

不加班的十个理由

理由1. 让你更有效率  多数的办公室工作十分繁琐,没有明确的开始与结束。正由于事情千头万绪,你很容易这个做一点、那个进行一半,结果没有一件有结果,迫使你以加班来赶工,一方面也安慰自己的心理。  但是...
  • kevinhalu
  • kevinhalu
  • 2006年09月13日 12:57
  • 983

转正申请理由

试用期已满,符合试用期内的工作要求,得到领导认可,胜任岗位职责,和同事相处愉快,希望能够正式留在公司,为公司的发展做贡献。...
  • netanimals
  • netanimals
  • 2011年09月23日 09:38
  • 8266
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:不用模式的理由
举报原因:
原因补充:

(最多只允许输入30个字)