MonkeyPatching is the act of changing code that is not in your code base. (by replacing preexisting methods, ''not'' by extending classes, at runtime.)

This practice is possible in languages that allow "reopening" class definitions or replacing existing methods, often at runtime.

Not related to CodeMonkey

----
'''Micro history'''

Monkey patching, while not described in those terms, was first used in Smalltalk (need ref).

Other languages using it: Ruby, Python, ???

----
'''Uses of MonkeyPatching'''

There are many reasons why people do that. Here are some on the top of my head :

Patching external projects:
*  Sometimes, your code depends on a broken library. 
  
*  In compiled language, either you have access to the code and you re-compile it with your patch, or you're stuck submitting a bug report and waiting for the maintainers to release a fixed version of the binary.
  
*  In dynamic languages, you can also decide to replace that method at runtime with your own code. The patch is theoritically removed once the bug is fixed.

Coding "DSL":
*  Some projects that specialize the language for a task like to extend the core classes with domain specific methods to build a new "syntax". This is not a good practice but not necessarily avoidable, especially when you don't have access to the AST or a good macro system.
*  Language with namespaces can restrict the object extension in a particular portion of the code. But again, namespaces are not always available.

Malicious intent:
*  Mostly in JavaScript, various json attacks consisted of changing the core objects so that when the json object would be evaluated, some unwanted script would be executed.

----
'''Risks of monkey patching'''

The security risk apart, the biggest threat of monkey patching is that it can lead to hard to debugging code. The code describing an object is no longer only in one place. It can lead to long debugging sessions where the developer doesn't understant why the code and the runtime are behaving differently. Over the time, the code base also become increasingly difficult to maintain ; the monkey fixes are still in place while the library has fixed it's code, and no-one remembers why the fix is there in the first place ; the developer must also be aware of all the places where the code lies (keeping job by obscurity). Finally, money patches often use internal data structures, which is agains the common usage of abstraction.