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).
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. The word guerrilla, homophonous with gorilla (or nearly so), became monkey, possibly to make the patch sound less intimidating. 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, Python, 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.
Monkey patching is used to:
- Replace methods / classes / 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).
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.
- 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
- 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.
The following Python example monkey patches the value of Pi from the standard math library.
>>> import math >>> math.pi 3.141592653589793 >>> math.pi = 3 >>> math.pi 3 >>> ================================ RESTART ================================ >>> import math >>> math.pi 3.141592653589793 >>>
|Wikiquote has quotations related to: Monkey patch|
- Aspect-oriented programming
- Self-modifying code
- Extension method in C#
- Category in Objective-C
- Dynamic loading
- Limi, Alexander; Shane Hathaway (2005-12-23). "Monkey patch". Plone Foundation. Archived from the original on 2008-06-04. Retrieved 2008-07-03.CS1 maint: BOT: original-url status unknown (link)
- "Refining Ruby". 2013-02-27.
- Biswal, Bimal. "Monkey Patching in Python". Software Technology Tips. Mindfire Solutions. Retrieved 9 December 2013.
- "New in Rails: Module#alias_method_chain". 2006-04-26.