那么，“设计模式是否缺少语言功能”？[关闭]

我在程序员那里看到了这个问题的答案：对设计模式和OOP实践的思考如何在动态和弱类型语言中发生变化？在那里，我找到了标题为直截了当的文章的链接：设计模式缺少语言功能。但是在我发现片段对我来说似乎很吸引人的地方，并且可以凭经验加以验证，因为这样做有诱因，例如：

PaulGraham说：“ Peter Norvig发现，设计模式中的23个模式中有16个在Lisp中是'不可见的或更简单的'。”

或另一句话证实了我最近在尝试使用JavaScript模拟类的人中看到的内容：

当然，没有人会说“功能”模式，“类”模式或我们认为理所当然的许多其他事情，因为大多数语言都将它们作为内置功能提供。OTOH，使用纯PrototypeOriented语言的程序员？可能会发现使用原型模拟类很方便...

我还考虑到设计模式是一种交流工具。因为即使我参与构建应用程序的经验有限，我也可以将其视为反模式（无效和/或适得其反），例如，这迫使一个小型PHP团队学习中小型Intranet App的GoF模式。我知道规模，范围和目的可以决定什么是有效的和/或富有成效的，但是我仍然没有找到有关这方面的技术概述。

我看到了一些小型的商业应用程序，它们将功能与OOP混合在一起并且仍然可以维护，并且我不知道是否有很多应用程序需要使用python编写单例，但是对我来说，一个简单的模块可以完成同样的事情。

那么，是否有研究，详尽的文章或其他形式的博览会考虑了设计模式，变通方法，更简单的实现方式或语言功能的替代？

我不了解任何将所有这些因素都考虑在内的深入讨论或研究。

也就是说，我认为“设计模式只是修补OO语言中缺少的功能”的论点有点薄。是的，某些设计模式正是这样，它们填补了某些其他语言X甚至不存在的常见缺陷。这些通常是您的底层，更简单的设计模式，例如GoF书中的某些原始样式。

但是设计模式远远超出了那些简单的模式，并且称它们为缺少语言功能会激发想象力。浏览Fowler的企业应用程序模式目录，并思考如果它们全部都是语言核心定义的一部分，那将会是什么样。我猜您最终将获得针对企业应用程序的域专用语言（DSL）（这是一种非常复杂的语言）。

这就是事实，设计模式是针对特定问题提出可重用解决方案的方式（通常以通用的通用语言应用）。这也是交流的源头。如果您告诉我“我们使用Active Records”，那么我已经对您的应用程序了解很多，而无需花费几分钟来讨论各种方法是什么。是的，设计模式确实在语言规范中打了补丁。这就是他们所做的一切吗？不-不能远射。

编辑：

在某种程度上，我要说的是，模式使OO练习者可以在更高的层次上进行思考，并几乎为他们的环境构造一种DSL类型，同时保持其语言的语法范围内。是的，我已经看到了将它们应用于任何地方时会发生什么情况（请参阅：AbstractSingletonProxyFactoryBean，是的，它存在），或者认为它们是某种灵丹妙药。关键是，尽管他们需要很长时间才能真正适应，但实际上应该通过使事物在较高水平上可预测/可理解来降低复杂性。这与针对您的语言缺陷的补丁包非常不同。

编辑2-添加了AbstractSingletonProxyFactoryBean反示例，以使模式有趣。公平地说，从AOP光源观看时，即使这个反例也是可以辩护的。