Monkey Patch猴子補丁編程方式及其在Ruby中的運用

何謂猴子補?。∕onkey Patch）？在動態(tài)語言中，不修改源代碼而對功能進行追加和變更。

使用猴子補丁的目的：
1、追加功能
2、功能變更
3、修正程序錯誤
4、增加鉤子，在執(zhí)行某個方法的同時執(zhí)行一些其他的處理，如打印日志，實現(xiàn)AOP等，
5、緩存，在計算量很大，結(jié)算之后的結(jié)果可以反復(fù)使用的情況下，在一次計算完成之后，對方法進行替換可以提高處理速度。

Ruby的類都是開放類，即在類定義之后還可以任意添加內(nèi)容， 這就使得在Ruby中使用猴子補丁變得特別容易了。另外，Ruby還提供了對方法、類和模塊的進行操作的功能，讓我們使用猴子補丁更加得心應(yīng)手。Ruby提供的基本功能如下：
      alias：給方法另起別名
      include：引入其他模塊的方法
      remove_method: 取消本類中的方法
      undef:取消方法 
     
在 Ruby 中使用 Monkey Patch
我當(dāng)時遇到的場景是這樣的：

我司使用第三方庫 fog 進行 EC2 的操作。創(chuàng)建實例等很多命令都需要設(shè)置實例類型這個參數(shù)。在 fog 里，EC2 的所有類型都定義在 fog/aws/models/compute/flavors.rb 的 FLAVORS 數(shù)組里。如果設(shè)置的類型不在 FLAVORS 數(shù)組里，fog 都會視作是無效的參數(shù)而報錯。

后來，亞馬遜發(fā)布了新的實例類型 D2。雖然 Ruby 的第三方社區(qū)非?；钴S，但是 fog 的開發(fā)社區(qū)還是沒有及時添加 D2 到 flavors.rb 里；而我司的工作又迫切需要使用 D2 類型的實例。

背景交待完畢，接下來看看有什么樣的解決方法。

方法一：我們可以向 fog 提交一個 Pull Request 來添加新類型。

但是這個方法行不通。我們使用的 knife-ec2 對 fog 的版本依賴必須是 1.25.*，但是 fog 已經(jīng)更新到了 1.31.0，而且 fog 從 1.27.0 開始結(jié)構(gòu)上有很大的變化。顯然，我們不可能再等 knife-ec2 升級支持新版本的 fog，所以我們提交 Pull Request 更新 fog 不能解決問題。

方法二：手動更新舊版 fog 既然不能使用最新版的 fog，我們可以手動編輯 1.25 版的 fog，再打包成 Gem 使用。這個方法比前一個方法更容易操作，但是帶來的問題時不易于維護。為了一個極小的改動，把自己的代碼加入到第三方庫中總是讓人覺得不夠「干凈」。

最后，在同事的指點下，我采用了第三種方法，即 Monkey Patch。我在我司的 Ruby 項目里添加了一個文件 lib/PROJECT_NAME/monkey_patches/flavors.rb，接著在文件中添加以下代碼來修改 fog/aws/models/compute/flavors：

require 'fog/aws/models/compute/flavors'

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_FLAVORS = FLAVORS + [
    {
     :id => "d2.xlarge",
     ...
    },
    {
     :id => "d2.2xlarge",
     ...
    },
    {
     :id => "d2.4xlarge",
     ...
    },
    {
     :id => "d2.8xlarge",
     ...
    }
   ]

   redef_without_warning :FLAVORS, NEW_FLAVORS

  end
 end
end

總結(jié)
通過在自己的代碼中添加一個 Monkey patch，我們成功地實現(xiàn)了向 fog 中動態(tài)添加新實例類型。我司終于可以使用 fog 創(chuàng)建 D2 類型的機器了；而且這個方法改動的代碼量最小，也更加容易維護。

Monkey Patch 并非是完美的解決方法，它會引入一些陷阱。所以這個技巧在軟件工程領(lǐng)域還有一些爭議。不過，我還是覺得 Monkey Patch 是一個不錯的零時性解決方法。