设计模式批评来源

我所遇到的大多数对设计模式的批评都与对它们认为是良好的面向对象实践的结构和标签的厌恶有关。大多数模式归结为编程到接口,以及其他 SOLID principles . 这种感觉是,当我们教授模式时,我们会让开发人员,特别是初级开发人员,尝试将所有问题塞进他们所学的模式集合中,这会比他们采取更“直截了当”的方法产生更迟钝和麻烦的问题。

我倾向于同意这样一种观点:一旦你开始学习模式,你往往会过度使用它们,然而,通常情况下,你很快就会走出这个阶段,进入一个更有生产力和专业性的软件职业。

作为奖励, here is a bit of mild criticism from Jeff Atwood 和 some critical insights from Mark Dominus

Alan Kay自己对模式非常挑剔,因为他不认为软件应该如此吹嘘。 Here's a 2012 Dr. Dobbs interview with Kay .

“编程中最糟糕的事情是从10件最糟糕的事情中选出一件,这是一个非常流行的基于模式语言的运动。当克里斯托弗亚历山大第一次在建筑中这样做时,他正在研究2000年来人类使自己舒适的方式。所以事实上是有原因的,因为他正在处理一个没有太大改变的基因组。我想他从中得到了几百个有价值的图案。但是在计算中尝试这样做的错误是假设我们对编程一无所知。因此,从今天的编程实践中提取模式会以一种不值得的方式使它们变得高尚。这实际上给了他们更多的声望。”

对设计模式的一大批评是一些设计模式到底有多“通用”。例如,在缺乏lambdas/一级函数的语言中,策略模式实现似乎更为相关(也更为复杂)(比较Java与Ruby,甚至与C#“函数”方法, here ).

理解力 和 描述 实现

当然,我也同意许多企业设计模式不适合纯功能语言。但我也相信功能世界也有自己的一套设计模式(比如 Monad

设计模式通常是以特定的编程语言(通常是java或C++)的一套技巧来呈现的。通常不解释什么时候和为什么需要使用一个模式,以及什么时候最好不要使用它。通常不会解释在完全不同的编程语言中会发生什么。

因此,人们会有这样的印象:1)设计图案来自天空,由天才发明;2)GoF书籍需要记忆;3)图案需要在每一种情况下不断地应用。

在我看来,设计模式是高度特定于语言的(LISP的“设计模式”集合与Java完全不同)和特定于问题的(取决于项目,您使用或不使用模式,即使它“理论上”适用于代码中的这个位置)。GoF书是Java语言手册的一个有用的伙伴,但不是一套关于“一般编程”的永恒原则。

大约十年前,设计模式被大肆宣传;在我看来,大多数批评都是关于对应用程序进行总体架构设计,并尽可能地应用所有可以想到的模式。这场激烈的辩论是相当无聊的,当你把咆哮的因素去掉-是的,太多的东西是不好的,对没有经验的程序员用锤子一切看起来像钉子。

有时,有人会发现他一直在做的事情有一个名字,并评论它不应该有一个名字(没有一点设计模式是关于命名有时显而易见的事情,以便您可以谈论它们)。

除此之外,我还没有看到很多关于设计模式的有效批评。它们确实存在,有时是有用的,当有人凌晨3点叫醒你时,你不必知道所有这些,就这样。:)

在经历过GoF书籍出版(ca 1995)的时代之后,我记得我读到一个主要的动力(或者至少是引起如此多关注的原因)是OOD对于大多数开发人员来说仍然是新的。人们根本不了解如何制作物体。

所以这本书展示了一些制作类的常见模式以及它们是如何协同工作的。

因此,这是一种批评:它现在可能没有当时那么重要。在那之后的几年里,框架的数量(尤其是在Java中)并没有之后的几年那么多。现在,您可以找到许多优秀的面向对象代码示例。如果一些作者把非常好的OO代码库放在一边,然后写一些书来说明为什么他们认为它们如此出色,这不是很好吗?

我确信设计模式有助于构建编程技术方面的教育课程,但我认为它们成为软件行业的通用语言并没有帮助。作为沟通设计的一种方式,它们可能会适得其反,因为它们迫使设计符合既定的模式,它们允许设计被描述得过于随意,它们迫使试图理解设计的任何人阅读一本关于设计模式的书。