将方法添加到您在javascript中没有的现有类中

Question

如果只是添加新方法而不是改变现有的方法行为，它是否仍然被称为猴子修补？这叫什么？

示例：

String.prototype.contains = function(needle) { return false; }

这可能不是最好的例子，但它显示了如何实现这一点。

这种技术的一些缺陷是什么，以及有哪些试图绕过它们呢？

Answer 1

它仍然被称为猴子修补。任何对类本身的修改，如果发生在与其官方声明相去甚远的地方，都是猴子的修补。

猴子修补国际海事组织有两个主要缺陷：

1. 方法定义变得更难搜索。当您想要查看方法的定义时，通常会转到类的定义。当该方法被猴子修补时，该方法的代码和注释就不会出现--甚至更糟的是，如果该方法被替换，那么原始的方法就会出现，而没有迹象表明它被其他什么东西取代了。
2. 您现在依赖于隐藏的模块加载。是的，您一直依赖于模块加载，但是现在依赖关系变得更加隐式了。通常您知道，如果您要创建一个新的Foo，您需要首先加载foo.js (或者在其中定义的模块Foo )。或者，如果您从其他地方接收到一个Foo，您就知道foo.js是在那里加载的。即使您以某种方式创建了一个Foo，而没有加载foo.js，因为其他人为您加载了它，而且其他人删除了加载foo.js的命令，当您的代码中断时，它通常很容易解决--您会得到一个错误，即Foo是一个未知的标识符，因此您可以查看它的定义并加载它。猴子打补丁可不容易。unrelated.js可以添加Foo.bar，而且您可能不用自己加载unrelated.js就可以使用它。然后有人删除了它对unrelated.js的依赖，或者您创建了一个新脚本并加载了foo.js，突然您的Foo对象不再拥有bar。在你意识到你需要加载unrelated.js之前，你要把头撞到墙上几次。

我的解决方案？如果需要使用猴子补丁，请尝试将其限制为框架和基础结构代码，而不是在库或应用程序代码中使用。这大大降低了风险，因为：

• 框架和基础设施已经被允许重新定义语言的规则。Rails是一个值得注意的例子:您已经深深地意识到，您已经不再对Ruby进行编程了--您正在编程RoR --所以猴子修补类只是您需要注意的另一个修改。
• 框架和基础设施通常处理自己的模块加载，以确保它们正常工作，这样它们就可以保证加载所有的猴子补丁代码。
• 框架和基础设施有自己的约定，如果您知道这些约定，您可以很容易地找到猴子修补方法的定义。

P.S.：一些编译后的静态语言在C#或Rust的struct/impl分离中有一些类似猴子补丁的扩展方法。这些工具没有这些缺陷，因为您定义的方法没有成为类的一部分。它们只使用类的命名空间，并且仍然属于在其中定义的模块/作用域。