先说清楚一个概念：所谓猴子补丁（Monkey Patch），就是在不修改源代码的前提下，给一个动态语言的对象追加或替换方法。

说白了，就是“运行时偷偷换掉”某个方法或常量，让程序按你想要的方式跑。

为什么要用猴子补丁

通常会有以下几种需求：

• 追加功能
• 改变已有行为
• 修复第三方库的bug
• 在方法执行前后插入钩子，比如打日志、实现AOP
• 做缓存，一次计算后直接替换成结果，省得每次重新算

Ruby 为什么特别适合 Monkey Patch

Ruby 的类都是开放类，定义完后还能往里随便加东西。

因此，猴子补丁在 Ruby 里用起来特别顺手。再加上 Ruby 本身提供了 alias、include、remove_method、undef 等操作，让补丁玩得更溜。

在 Ruby 中使用 Monkey Patch

来看一个真实的例子。某团队用第三方库 fog 管理 AWS EC2 实例。

创建实例的时候，很多命令都需要指定实例类型。而 fog 把所有 EC2 类型都定义在 fog/aws/models/compute/fla vors.rb 的 FLA VORS 数组里。

如果传入的类型不在这个数组里，fog 就直接报错。

后来 AWS 发布了新的 D2 系列实例。Ruby 社区虽然活跃，但 fog 的官方仓库还没来得及把 D2 加进 fla vors.rb。

问题在于：项目又急着用 D2 类型，必须尽快解决。

第一种思路：给 fog 提 Pull Request

这个方案行不通，因为当时用的 knife-ec2 强依赖 fog 1.25.* 版本。

而 fog 已经更新到 1.31.0，并且 1.27.0 之后结构大变。等 knife-ec2 升级支持新版 fog，遥遥无期。

第二种思路：手动修改旧版 fog 源码

也就是直接修改旧版 fog（1.25）的源码，再重新打包成 gem 使用。

这比提 PR 容易，但维护起来很麻烦。为了这么小一个改动，把自己的代码塞进第三方库，总感觉“不干净”。

第三种思路：使用猴子补丁

最后，在同事的建议下，团队采用了第三种方法：猴子补丁。

具体做法是：在项目里创建一个文件 lib/PROJECT_NAME/monkey_patches/fla vors.rb，然后写入以下代码，动态修改 fog/aws/models/compute/fla vors：

require 'fog/aws/models/compute/fla vors'

class Object

 def redef_without_warning(const, value)
  mod = self.is_a?(Module) ? self : self.class
  mod.send(:remove_const, const) if mod.const_defined?(const)
  mod.const_set(const, value)
 end
end

module Fog
 module Compute
  class AWS
   NEW_FLA VORS = FLA VORS + [
    {
     :id => "d2.xlarge",
     ...
    },
    {
     :id => "d2.2xlarge",
     ...
    },
    {
     :id => "d2.4xlarge",
     ...
    },
    {
     :id => "d2.8xlarge",
     ...
    }
   ]

   redef_without_warning :FLA VORS, NEW_FLA VORS

  end
 end
end

总结

通过这一个小补丁，团队成功地向 fog 动态注入了 D2 类型。

这样一来，项目终于能用新实例了。改动量最小，维护起来也清爽。

当然，猴子补丁不是完美方案。它容易引起不可预知的副作用，比如覆盖了其他依赖同名的常量或方法，导致诡异的问题。

所以，软件工程界对它的评价一直有争议。

但就事论事，在需要临时绕过第三方库限制的场景下，它确实是一个干净利落的“救急”手段。

《夸克》非常好用的免费AI浏览器

下载APP查看