是否有一种设计模式可以将方法注入到类中？

Question

我有一组可以协同工作的类（我正在用 javascript 进行编码）。

有一个父类和许多由父类实例化的子类。我有许多这些类的客户，每个客户都需要向父类或子类添加一个或多个方法。

我不是让每个客户端都从这些类继承（这是可行的，但由于子类而变得混乱），而是让这些客户端在实例化主类时将函数传递到父类中。

主类动态创建方法，客户端可以调用这些方法，就像它们一直存在一样。

我的问题是：

1. 这样做明智吗？
2. 我正在做的事情的设计模式是什么？

Answer 1

策略模式适用于在运行时获取“策略”的情况。可能适用于此。在这种情况下，策略是一个符合行为的类，即具有“执行”等方法。

装饰器模式也可能适用。它也是一种运行时模式，但增强了它在方法级别修饰的类。

因此，如果您动态选择一个类，则策略模式很好，如果您仅在运行时更改方法实现，则装饰器模式很好。

（我在 ircmaxell 的许可下采用了这个答案的装饰器部分）

Answer 2

我必须承认模式不是我的“事”——但你可以在 javascript 中完全做你想做的事。这就是所有框架如何完成“扩展”子“类”之类的事情（JavaScript 中没有类）。

如果你在纯javascript世界，你想使用：

foo.prototype.bar = function() {};

所以你可以在任何foo上调用bar，并且bar只存在于内存中一次 - 即通过每个 foo 对象在内存中引用同一个函数。因此，请小心您可能在该范围之外引用的任何变量。

每个库都有自己的插件架构来实现大致相同的目标（并且它们负责原型中的一些混乱/危险）

Answer 3

您应该提供一些代码，以便我们能够准确地了解您正在谈论的内容。

因为您没有：我只能猜测您没有使用原型。原型将是“面向对象”JavaScript 的“正确”设计模式。

当您在 JavaScript 中将函数/属性/任何内容添加到对象的原型时，所有实例（无论新的还是旧的）都会在其原型上接收函数/属性/任何内容。

在 JavaScript 中扩展原型非常简单，并且永远不应该变得混乱。如果确实如此，则可能意味着您将其过于复杂化了。

Answer 4

正如 hvgotcodes 所说，您正在描述策略模式，针对您的特定情况执行此操作的方式不是使用原型（从而影响类的所有对象。）

而是提供一个接受函数作为其值的成员。

例如

function MyClass() {
    this.myFunction = defaultFunction;

    this.defaultFunction = function() {
       // do something by default.
       alert("using default");
    }

    this.doFunction = function() {
       // something that calls myFunction.
       this.myFunction();
    }
}

---8< snip --------

// later on...

t = new MyClass();
t.doFunction(); // output 'using default'
t.myFunction = function(){ 
   // do something specific with this instance, when myFunction is called. 
   alert("customized for this instance.");
}
t.doFunction(); // output 'customized for this instance.'