“monkeypatching”背后的正式设计模式是什么？

Question

核心CS问题：Gamma中列出的设计模式等，哪些（如果有的话）涵盖monkeypatching？另外，对于什么类型的问题，monkeypatching是否合适与子类化？修补核心库类中的错误是一个，还有其他吗？我听到很多关于stackoverflow上的monkeypatching的sturm和drang，你们大多数人似乎对它有很强的疑虑，但作为一名程序员，我真的很喜欢封装通用功能的能力并将它们包含在我的rails中的对象模型中。

以thinkbot-paperclip为例，为什么我想要将今天存在的monkeypatch方法的子类化？

谢谢， -Eric

Answer 1

我不认为monkeypatching是一种设计模式 - 核心类扩展是一种他们似乎忽略的语言特性。

关于其余部分，请查看Jeff Atwood对this article on his blog的看法。

在他（和我）的观点中，monkeypatching的最大问题是它可以使调试变得非常困难，如果它修改了现有方法 - 我们人类无法跟踪所有“这里和那里的小片段”以及机器呢。子类坚固清晰的分离。

所以我的monkeypatching个人规则是：

• 如果你可以在没有monkeypatching的情况下完成它并且它可以正常工作，请不要使用monkeypatching。
• 您可以向类中添加新方法，但不能修改现有方法。
• 以非常明显和明显的方式进行 - 即/ lib中名为string_extensions.rb的文件，而不是隐藏的/myvendor/submodule/se.rb文件。
• 应该是本地的;不使用库的类应该不受影响。

现在，举个例子：Paperclip。

• 据我所知，它为您的ActiveRecord类添加了方法，但不修改现有的方法
• 您必须向使用回形针的类添加has_attachment指令，否则它们不会受到影响。

因此，这些更改是本地化且显而易见的（我实际上认为它设法改进调试：我们人类更容易阅读has_attachment而不是class MyModel < Paperclip::ActiveRecordWithAttachment）。< / p>

对于这种情况，子类化也是一个坏主意，因为除了使用子类的另一个插件之外，你将无法使用paperclip - rails是单一继承的。

在Paperclip的案例中，它与其附件显然是has_a关系，而不是is_a。有人可能会认为它不适合使用子类化。

最后，我想指出Paperclip在某些情况下需要子类化（你必须使用子类来创建回形针处理器）。