Monkey patch

A monkey patch is a way for a program to extend or modify supporting system software locally (affecting only the running instance of the program). This process has also been termed duck punching, based on the term "duck typing".^[1]

Etymology

The term monkey patch seems to have come from an earlier term, guerrilla patch, which referred to changing code sneakily – and possibly incompatibly with other such patches – at runtime.^[2] The word guerrilla, homophonous with gorilla (or nearly so), became monkey, possibly to make the patch sound less intimidating.^[2] An alternative etymology is that it refers to “monkeying about” with the code (messing with it).

The definition of the term varies depending upon the community using it. In Ruby,^[3] Python,^[4] and many other dynamic programming languages, the term monkey patch only refers to dynamic modifications of a class or module at runtime, motivated by the intent to patch existing third-party code as a workaround to a bug or feature which does not act as desired. Other forms of modifying classes at runtime have different names, based on their different intents. For example, in Zope and Plone, security patches are often delivered using dynamic class modification, but they are called hot fixes.

Applications

Monkey patching is used to:

• Replace methods / attributes / functions at runtime, e.g. to stub out a function during testing;
• Modify/extend behaviour of a third-party product without maintaining a private copy of the source code;
• Apply a patch at runtime to the objects in memory, instead of the source code on disk;
• Distribute security or behavioural fixes that live alongside the original source code (an example of this would be distributing the fix as a plugin for the Ruby on Rails platform).

Pitfalls

Carelessly written or poorly documented monkey patches can lead to problems:

• They can lead to upgrade problems when the patch makes assumptions about the patched object that are no longer true; if the product you have changed changes with a new release it may very well break your patch. For this reason monkey patches are often made conditional, and only applied if appropriate.^[5]
• If two modules attempt to monkey patch the same method, one of them (whichever one runs last) "wins" and the other patch has no effect, unless monkey patches are written with a pattern like alias_method_chain.^[6]
• They create a discrepancy between the original source code on disk and the observed behaviour that can be very confusing to anyone unaware of the patches' existence.

Even if monkey patching isn't used, some see a problem with the availability of the feature, since the ability to use monkey patching in a programming language is incompatible with enforcing strong encapsulation, as required by the object-capability model, between objects.

See also

• Aspect-oriented programming
• Self-modifying code
• Extension method in C#
• Category in Objective-C

References

1. Delabar, Eric (2008-05-02). "Duck Punching JavaScript — Metaprogramming with Prototype". Retrieved 2008-07-03.
2. Limi, Alexander; Shane Hathaway (2005-12-23). "Monkey patch". Plone Foundation. Retrieved 2008-07-03.
3. "Refining Ruby". 2013-02-27.
4. Biswal, Bimal. "Monkey Patching in Python". Software Technology Tips. Mindfire Solutions. Retrieved 9 December 2013.
5. "Maintainable JavaScript: Don’t modify objects you don’t own". 2010-03-02.
6. "New in Rails: Module#alias_method_chain". 2006-04-26.