对“设计模式”的正确态度

多年以前，我一直反对设计模式。因为认为设计模式并不能帮助提升产品的输出特性，或者产品本身的生产效率。多年以后，这个命题仍然是正确的。因为随着软件开发技术的逐渐发展，人们对整个软件技术的概念越来越清晰。特别是设计模式，它在软件开发中的地位显然跟最终产品并没有任何关系。或者说，至少，它不是一种以产品输出特性或生产效率为论域的技术。它跟产品本身完全没有任何关系。

至少关系很少。

GOF即四人帮的设计模式分成三个类型：创建，行为，结构。描述的全是静态代码的结构。或者说全是从静态代码的角度出发考虑解决问题的。所有的模式，都跟运行时没有任何关系。也没有对运行时特性即输出特性，或者生产效率作出任何讨论。从头到尾，它所讨论的其实都是围绕着设计者本身而进行的。所有的讨论结果也全是围绕着设计者本身的：有关设计者如何进行设计。这里的设计，指的是作为一种工作，意义上的设计。而不是作为一种产品，意义上的设计。因为，如果是产品意义上的设计模式，那么讨论的中心点显然将会涉及诸多的软件产品运行时也即输出特性。所有的模式，都应该跟一定的产品输出特性联系起来。只有这样，才能说这是一种“产品设计模式”。比如，建筑设计模式（事实上，很多软件技术作者在这上面犯下很严重的错误，并因此误导或耽误了很多初入软件开发领域的新手------因为建筑设计模式是一种产品设计模式，而软件设计模式却不是。它只是一种设计者设计模式。也就是说，它只是一种工作模式------因为很明显地，它所研究的范围，到静态代码也即工作者的全部工作成果为止。它并没有在此基础上向上前行或尝试前行哪怕一步---它的意思是，照着这些模式进行设计，你便能得到大部分你想要的东西---我不相信有任何人能真正相信这些东西。因为如果果真如此，为什么我们还需要学习别的东西？比如软件架构，质量控制，项目管理，软件进化。。。。。。等等。我需要学习或研究很多别的东西，是因为它真的，并不是全部。但这并不意味着对它的否定。因为作为一种切入角度，它显然可以作为一种软件知识存在于计算机科学中）。

作为一种工作技巧，设计模式却可以是一个非常好的面试题目。因为显然，任何技术或知识到最后必须归纳于工作才能发挥其价值。比如，软件进化，项目管理，质量控制，软件架构，，无论研究得多么深入并且从中得出如何深刻的结论，如果不转化成具体的设计行为，它们的价值就不可能得到发挥。从这个角度看，的确，设计模式是一个非常好的经验聚集或保存点（现在回想，好象这也的确是四人帮在作品中的观点------这些模式存在的价值在于传承经验）。而对于任何一个软件从业者来说，所面临的知识工具显然只存在两种：一是已经存在即有经验的领域；二是不存在或不确定所以需要继续研究的领域。

基于知识的认识论本质，这两个领域显然将长期或永远地同时存在于整个软件技术领域。所以，长期或永远地意识到它们的同时存在，对于从事软件工作显然非常重要。否则就很容易剑入偏锋。比如，重复发明轮子或因为没有意识到所涉及领域的新颖性或未知性而使用了错误的技术。

这才是对设计模式的正确态度。