design-patterns - 设计模式真的是语言的弱点吗？

Question

今天的模式应该是be seen as defects or missing features in Java and C++ ？

• 子例程是20世纪50年代和60年代机器语言的设计模式。
• 面向对象类是 70 年代的 C 设计模式。

• 访问者、抽象工厂、装饰器和外观是当今 Java 和 C++ 的设计模式。

  明天的语言会是什么样子？ 他们会有什么模式？

Answer 1

一些规范的设计模式——适配器、工厂、命令、访问者等——是融入其他语言的功能的近似值。从我的头顶上掉下来:

• C# 中的事件处理程序是观察者模式的内置版本。想一想，如果您每次都必须滚动自己的观察者，您将如何在 C# 中连接事件。

• 访问者模式是 multimethods 的详细近似值, message forwarding ，或者 pattern matching 的一个非常弱的形式.

• 命令模式包装了特定的行为，以便您可以在方法之间传递对象，这或多或少近似于一流的函数。

• 策略模式允许您动态地将行为插入到对象中，以便您随时可以通过将一种行为替换为另一种行为来修改对象。在函数式编程世界中，我们称之为函数组合。

• 抽象工厂模式接受一个参数并返回一个工厂作为结果。一般来说，您可以将工厂视为函数的基本包装器(更具体地说，是构造函数的包装器)。因此，您将参数传递给函数并得到一个函数作为结果，使这种模式非常类似于柯里化(Currying)。

• 装饰器模式允许您在运行时向对象附加或删除行为。在 JavaScript 中，借助“原型(prototype)”OO 模型，您可以添加或删除函数，而无需显式实现装饰器模式。

因此，我们有一堆设计模式来模拟其他语言固有的功能。功能嫉妒并不一定表明该语言的弱点 - 这是您需要一遍又一遍地编写的样板代码，这表明了语言的弱点。