Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been under impression, that monkeypatching is more in quick and dirty hack category, rather than standard, good programming practice. While I'd used from time to time to fix minor issues with 3rd party libs, I considered it temporary fix and I'd submit proper patch to the 3rd party project.

However, I've seen this technique used as "the normal way" in mainstream projects, for example in Gevent's gevent.monkey module.

Has monkeypatching became mainstream, normal, acceptable programming practice?

See also: "Monkeypatching For Humans" by Jeff Atwood

share|improve this question
11  
I would say that something named monkey patching is NOT considered good programming practice. Without even knowing what it is, just by the name of it. –  littleadv Apr 16 '12 at 10:05
    
What if 3rd party does not want to do the fix you need? –  user1249 Apr 16 '12 at 10:12
1  
@Thorbjørn: good question, on one hand I don't like monkeypatching, on other I don't quite like idea of cloning project and keeping local patches if it's just a minor issue. –  vartec Apr 16 '12 at 10:20
1  
@littleadv: ...then call it "hot fix" / "on-the-fly fix" or "runtime fix" and it sounds good right? ;) It's all the same. –  arnaud Apr 16 '12 at 13:27
1  
javascript is pretty much built around the concept –  ZJR Apr 16 '12 at 23:42
show 1 more comment

5 Answers

up vote 15 down vote accepted

No, but sometimes monkeypatch is a lesser evil (than having broken code :)). My general rules for monkeypatches in ruby are:

  • have a really good reason for monkey-patch (temporary critical hotfix is a good reason. Nice formatting of to_s method is not, unless you're working on ActiveSupport)

  • make them as transparent as possible: put them into specific place in codebase and separate files, write documentation describing the reason for monkeypatch (here's an example).

  • easy to remove - documentation should include info about removal and what to watch for. Lots of monkeypatches are temporary, so they should be easy to remove.

share|improve this answer
add comment

Yes, monkeypatching is very useful!

Somehow, names seem to be highly influencial on people's perception. Call it "monkeypatch" and it sounds bad, call it "hot fix" or "on-the-fly fix" and it sounds good.

Independently of that, I think the capability to alter methods/attributes/functions at runtime is a very useful thing. Even javascript people use it all day long without perhaps knowing it.

For instance:

button.onclick = function(e) { ...}

This simple line illustrates the fact that you alter the behavior of button. It was designed that way. Likewise, you could alter every other function but it would be silly to do so.

Now, for the question of delivering patches that way... well... why not. You just have to download a small patch instead of a big release. Heck, you could even patch a server without stopping it, great! And then, one day, you could also fetch the latest release for a bigger update. Fair enough. So yes, I vote for "runtime patches" as a good thing.

Interestingly enough, some languages like Erlang were even build around this concept. The capability to update a server on the fly.

Of course, in the end, and like with everything else, it's a matter of how you use it. You can make wonderful OO stuff and shitty one, it's all the same.

EDIT:

Let me add some case distinction, whether you are patching your own library or a third-party one.

...basically, what you do with such a patch is fixing a bug of your own or a third party library. In either case it's useful. For your own, it enables you to deliver a fix on-the-fly. For a third-party one, either you wait (several months?) until they fix it by themselves, or you do it now on your own. (you can still submit them the patch, so that they will fix it on their side). When they release their next lib version with the issue fixed, you can still, if you want update the library and remove the patch on your side.

Now, of course, if you use a patch to alter the behavior of a lib and alienate its purpose/way of working, then obviously that's a recipe for disaster. Even a monkey would see that ...well, I hope. ;)

share|improve this answer
    
Nobody says it's not useful. However, it's not a good practice in general. And "hotfix" and "on-the-fly fix" doesn't sound any better to me. –  Lukas Stejskal Apr 16 '12 at 13:43
    
Well, I find the capability of altering the behavior of an application on the fly very useful, even more if it is big one. Heck, you could even have the code storing the old method as backup and a command to automatically rollback on demand! The possibilities are tremendous! –  arnaud Apr 16 '12 at 13:56
    
I agree that it's a powerful and useful feature. But also very dangerous (esp. in Ruby), therefore it should be used with extreme caution (esp. for modification of standard and 3rd party libraries). Have you ever tried to maintain application depending on several monkeypatched 3rd party libraries? A recipe for disaster whenever you try to update some library. –  Lukas Stejskal Apr 16 '12 at 16:08
    
Yeah, I agree, if you use these patches carelessly, in unintended ways or abuse of them, it can quickly become messy. Like you can abuse any concept or make a mess with anything. However, otherwise, if they are well organized and transparent, and they all flow in the next big release, it looks clean to me. ...however, I have no experience with ruby libraries which are heavily patched. –  arnaud Apr 17 '12 at 7:22
    
...I added some comments on the latter case. –  arnaud Apr 17 '12 at 7:40
add comment

I believe that all patches are inherently risky due to their run-time nature, and inability to be caught at design-time.

They welcome runtime exceptions, and require complex debuggers and watches just to follow.

They are used when people SEAL classes, and so inheritance is impossible. However, there are better ways to extend objects without damaging them.

My two cents

share|improve this answer
add comment

Patching in general should be a last resort, monkey patching even more so. The issue is primarily one of maintainability.

A long time ago, my linux kernel had 3 separate patches applied to it, necessary for my video card driver and two proprietary applications I had. Two of them had conflicting changes, which meant I needed a 4th patch to resolve the differences between them. Now whenever a security issue was fixed in the upstream kernel, I either had to wait for the vendors of those 3 patches to release an update to the new kernel version, which took from one to six months, or I had to manually maintain the upstream security patches until the other patch vendors caught up.

After a few years, the vendors managed to get included in the upstream kernel source, and I was able to stop the balancing act, but you can see what a mess it was in the mean time. Don't inflict that on your programmers unless you have to.

share|improve this answer
add comment

No. It is not a standard technique for software development. It remains a workaround to solve an acute problem and has clear drawbacks. Violation of the Liskov Substitution Principle comes to mind. Monkey patching makes it seriously harder to reason about programs. For your own programs you should place the code where it belongs. For third party libs you will always live in the danger, that your patch won't work with the next version of the lib.

Of course monkey patching is useful if you know what you are doing and do not have the time to implement a SOLID solution. But you should never consider this a standard technique and build monkey patch upon monkey patch.

BTW, did you ever write a unit test for a monkey patch?

share|improve this answer
    
I don’t think you can apply LSP here. It has a very specific definition concerning subtypes. –  Konrad Rudolph Apr 18 '12 at 10:23
    
@KonradRudolph Monkey patching an object changes its type. In dynamically typed languages every type t with the same interface as type u is a subtype of u. If it walks like a duck... –  scarfridge Apr 18 '12 at 16:38
    
“… changes its type” – fair enough. Makes sense. –  Konrad Rudolph Apr 18 '12 at 16:45
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.