【问题讨论】：
标签： design-patterns
我遇到的大多数对设计模式的批评都与对他们认为只是好的面向对象实践的结构化和标签的厌恶有关。大多数模式归结为对接口的编程，以及其他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 件事中选出一个——有一个非常流行的基于模式语言的运动。当 Christopher Alexander 第一次在建筑领域这样做时，他正在研究 2000 年的方式人类已经让自己感到舒适。所以实际上有一些东西，因为他正在处理一个没有太大变化的基因组。我认为他从中得到了几百个有价值的模式。但是试图做的错误在计算中，假设我们对编程一无所知。因此，从当今的编程实践中提取模式以一种他们不应该得到的方式使它们变得高尚。它实际上给了它们更多的声望。”
【讨论】：
对设计模式的一大批评是关于某些设计模式的真正“通用性”。例如，Strategy Pattern 实现 似乎与缺乏 lambdas/一流函数的语言更相关（也更复杂）（我们可能会注意到here）。
但我认为这个论点忽略了设计模式确实存在这一简单事实：我们可以感知代码中的模式，任何代码。一旦我们注意到它们，我们就可以开始将它们作为一种清晰的、与语言无关的方式来描述和理解软件架构。因此，某些设计模式在某些编程语言中（或直接支持）更容易实现这一事实当然是需要注意的。但在我看来，将其作为反对设计模式的论据是荒谬的。
当然，我也同意许多企业设计模式不适合纯函数式语言。但我也相信功能世界也有自己的一套设计模式（比如Monad）。
最后，可以在Hacker News thread 上找到关于设计模式（即使 bit 混乱）的一个有趣讨论。来自用户@thom 的这篇帖子与我的观点相似：
重要的是要注意技术机制和设计动机之间的区别。是的，很多语言都可以传递函数，所以您可能认为策略模式不适用于您。然而我看到大量的 API 仍然需要大量的选项映射，并且不提供带有某种回调的配置，无论宿主语言多么简单。模式捕获设计选择与技术实现一样多。
【讨论】：
大约十年前，设计模式被大肆宣传；在我看来，大多数批评都是关于过度架构应用程序和应用你能想到的所有模式。当你把咆哮的因素排除在外时，这场激烈的辩论是相当无聊的——是的，任何东西太多都不好，对于没有经验的程序员来说，一切看起来都像钉子。
有时，有人会发现他一直在做的事情有一个名字，并评论说它不应该有一个名字（忽略了设计模式是关于命名有时是显而易见的事情，以便你可以谈论他们）。
除此之外，您基本上只剩下这样一个事实，即有些语言内置了一些模式，而另一些则没有，以及关于一些模式如何随着时间成为编程语言特性的学术争论。
除此之外，我还没有看到太多与设计模式相关的有效批评。它们肯定存在，有时它们很有用，当有人在凌晨 3 点叫醒你时，你不必知道所有这些，仅此而已。 :)
【讨论】：
设计模式通常以特定编程语言（通常是 Java 或 C++）的一组技巧的形式呈现。通常不会解释何时以及为什么需要使用模式，以及何时最好不要使用它。通常不会解释在完全不同的编程语言中会发生什么。
因此给人的印象是：1) 设计模式来自天上，由天才发明，2) GoF 书需要记住，3) 模式需要在任何情况下都得到应用，而且越来越多。
在我看来，设计模式是高度特定于语言的（LISP 有一组与 Java 完全不同的“设计模式”）和特定问题（取决于项目，您使用或不使用模式，即使它是“理论上”适用于您的代码中的这个地方）。 GoF 书是 Java 语言手册的有用伴侣，但不是一套关于“一般编程”的永恒原则。
【讨论】：
经历了 GoF 书籍出版的时代（约 1995 年），我记得读过一个主要的推动力（或者至少是引起如此多关注的一个原因）是 OOD 对大多数开发人员来说仍然是新事物。根本不知道如何制作对象。
因此，这本书的面世展示了一些常见的类制作模式以及它们如何协同工作。
因此对此提出批评：它现在可能不像以前那么重要了。那时，以及之后的几年，框架（尤其是 Java 中的框架）并不像之后几年那样多。现在，您可以找到很多优秀的面向对象代码的示例。如果一些作者把非常好的 OO 代码库的快照放在一边，并写一些关于他们为什么认为它们如此出色的书，那不是很好吗？
对我来说，这些模式的最佳用途是在看到它们时了解它们，了解其缺点（参见“访问者模式”并注意系统的哪些部分更容易扩展），并在编写时吸取这些教训你自己的代码。
【讨论】：
我确信设计模式有助于构建有关编程技术的教育课程，但我认为它们成为软件行业的通用语并没有帮助。作为交流设计的一种方式，它们可能会适得其反，因为它们迫使设计符合既定模式，它们允许对设计进行过于随意的描述，并且它们迫使任何试图理解设计的人阅读有关设计模式的书。
【讨论】：