根據維基百科,游擊補強(Guerrilla patch)是指執行時期動態改變程式碼,因為英文上同音於猩猩修補(Guerrilla patch),後來改稱猴子補丁(Monkey patch)聽來比較不嚇人一些。

實際上,不同語言社群中,猴子補丁會有不同的定義與作法,大致都是指在不修改既有原始碼情況下,動態修改程式運作行為的能力,而且通常指那些非常開放的修改方式,猴子補丁適切地形容了這類修補行為,連猴子也會做,甚至帶有粗魯輕率的意涵!

猴子補丁的優點和危險性
在JavaScript執行猴子補丁,是相對容易的。

舉例而言,並非瀏覽器都支援JavaScript陣列的forEach方法,在偵測瀏覽器不支援陣列的forEach時,可使用程式碼Array.prototype.forEach = function(callback) {...},使得陣列實例都可執行forEach方法,如果想刪除陣列某個方法,也可以輕易地將Array.prototype上該名稱設為undefined,來達到目的。

JavaScript是1995年5月的短短十天內建立,為了讓使用者可對這倉促建立的語言進行修補,Brendan Eich賦于JavaScript極大可塑性,對於一個物件,開發者可進行幾乎完全的改造。在《Effective JavaScript》前言中,Brendan Eich談到「開發人員能夠藉此編輯標準物件,以克服一些臭蟲」、「在舊瀏覽器中模擬出未來的新功能性」,甚至「以其他語言為模式,建立了工具組(Toolkit)或框架程式庫」。

Brendan Eich的言論中說明了猴子補丁的優點,在不修改標準或第三方程式庫原始碼下,開發者能在發現臭蟲時進行即時修正,可以對原生(Native)物件或第三方程式庫進行新功能擴充,像是在某瀏覽器中偵測到物件沒有某方法時,對物件本身或原型增添方法,讓應用程式相容於新舊或不同瀏覽器。

既然可在不修改既有原始碼下修正臭蟲、擴充功能,可將這些修正臭蟲、擴充功能的程式碼,設計為工具組或框架程式庫,當引入這類工具組或框架程式庫時,就可以全面修正、擴充語言的功能,甚至改變或賦予語言新樣貌。因此,像是Prototype、jQuery程式庫,或後來的Node.js都是具體實例。

在不修改標準或第三方程式庫原始碼下,就可隨意地改變物件行為,聽來確實是很誘惑人的功能,然而這也是猴子補丁最大的危險性,因為修補太過容易,而修改後的行為又會影響整個應用程式,因而輕率的猴子補丁,很容易就造成程式其他地方異常。

舉例而言,JavaScript的String有個match方法,可傳回符合正規表示式(Regular expression)的字串,否則傳回null,基於某個理由,開發者可能想撰寫str.match(re).length,然後當match傳回null時,這段程式碼會出錯,因而他猴子式地修補了match,使之找不到符合正規表示式時傳回空字串,如果應用程式中另一名開發者撰寫了str.match(re) === null ? value1 : value2,那麼他的運算就會傳回錯誤結果。

猴子補丁的另一個問題在於,兩個以上的程式庫嘗試修改相同方法時,就會出問題。

舉例而言,若有程式庫嘗試修改Array.prototype.filter為留下符合條件的元素,另一程式庫修改為去除符合條件的元素,那麼同時引入兩個程式庫時,使用filter方法就有一半機率會出錯,這取決於哪個程式庫覆蓋了另一程式庫的定義,當程式庫引入時大量修改了物件行為,這種錯誤就容易發生。

可以修改原生物件的行為也是令人爭議的。舉例而言,如果網頁中引入Prototype程式庫,因為它會對原生物件進行修改,使得判斷物件行為是來自原生或是程式庫修改時,界線變得糢糊,令程式中某些地方依賴了Prototype修補的行為而不自知,在其他沒有引入Prototype的環境中,也容易因為試圖使用Prototype修補的行為,而錯誤頻繁。

要避免輕率粗暴的猴子補丁,方式之一就是僅新增物件原本沒有的方法,因為是新增,程式沒有其他部份依賴在這方法上,不影響程式其他地方。

為了避免多個程式庫嘗試修改相同方法,可以藉由測試來防護,像是在偵測到陣列本身沒有forEach方法時才予以新增,如果陣列本身具備forEach方法,然而開發者希望有個迭代方法,能於迭代時同時提供索引與元素,那麼不要直接修改forEach,而可以是新增一個forEachWithIndex方法來補強。

想掌握最新IT動態,歡迎按贊加入iThome粉絲團
如果要以猴子補丁重新定義方法,那麼不應改變該方法在文件上載明的行為。如果文件該方法不會拋出錯誤,那就不應該這麼做,如果文件聲明String的match找不到符合正規表示式的字串時,應傳回null,那就不應重新定義為傳回空字串。

以猴子補丁重新定義一個方法,可以是為了修補臭蟲,或是在原本行為上加以額外動作,此時可在重新定義方法時,令最後傳回原方法的結果。例如orgIndexOf = String.prototype.indexOf的話,可如下重新定義String.prototype.indexOf:

String.prototype.indexOf = function(ch) {
// 前置處理
rtv = orgIndexOf(ch);
// 後置處理
return rtv;
};

類似地,先前提到String的match方法需求,可以新增noNullMatch方法,並於其中委託給原match方法的方式來修補。若如下修補程式的話,就可以用str.noNullMatch(re).length來解決先前需求:

String.prototype.noNullmatch = function(re) {
var found = this.match(re);
return found === null ? '' : found;
};

在原生物件上新增方法是有爭議的,極端的建議是,絕對不要對原生物件進行修改,像是jQuery程式庫就不對原生物件進行擴充,而使用jQuery物件來對選取之物件操作,如此判斷物件行為是來自原生或程式庫補強,界線就變得清晰。

在標準物件上新增方法的理由之一是,該方法已經是事實上的(de facto)標準,例如陣列的forEach方法,在〈JavaScript Garden〉文件中亦建議擴充原生物件的另一理由是提供相容性,像在舊JavaScript引擎中提供Object.extend方法。《Effective JavaScript》書中條款42建議「任何會修改共用原型的程式庫,最起碼都應該在說明文件中清楚地指明」。

從開放性的控制中學習最佳實踐
以上對於避免粗暴的猴子補丁之建議,部份來自《Effective JavaScript》書籍與〈JavaScript Garden〉文件,部份來自《Well-Grounded Rubyist》書中13.2,有關修改Ruby核心類別與模組的內容。

Python也可進行猴子補丁,然而不允許修改標準類別,此外,上述建議仍適用;《Well-Grounded Rubyist》中談到「學習控制Ruby的開放性,部份是與程式設計技巧有關,然而大多是有關於最佳實踐」,這些實踐很大程度可共通於不同語言。

不改變方法在文件上載明的行為,套用在Java於子類重新定義方法時也適用,如果子類重新定義方法時,行為與父類方法有異,在原本允許替換子類實例的場合,程式行為就有可能異常。

需要在原有行為上加以額外動作時,裝飾器(Decorator)模式將實際動作委託給原物件,並於前後加上額外行為,裝飾器物件上也可新增方法,以符合擴充功能的需求。

如果無法吸取這些最佳實踐來控制程式行為,即使程式不提供猴子補丁的可能性,開發者寫程式也只會像個猴子,而不是靈活的游擊隊員了。

想掌握最新IT動態,歡迎按贊加入iThome粉絲團

作者簡介


Advertisement

更多 iThome相關內容