I've heard a lot of oohs and aahs about how monkey patching is so cool or monkey patching is the worst thing on earth. I have the idea that it's not good if you write some code and then someone else changes its functionality to do something else. But I'm looking for a concrete example of a situation where this could really hurt you. I mean, I write code all the time and then my coworkers make changes to it. So, how is monkey patching any different from that? What's the worst that could happen?
+3
A:
Monkey patching hides changes to an object from the rest of the object, and from the object's documentation. It's very easy to go use that object, check it's documentation to be sure it does what you expect, and then find out later it doesn't quite work that way.
This is especially bad if you work on a project that sees developer churn, where you need to worry more about how to bring new developers up to speed with your code base. New developers won't be aware of the nuances of your patches and you'll have a harder time getting good code out of them as a result.
As for the worst that could happen, what's the worst thing that could happen if there's a bug in your app? Could someone die because of a piece of equipment functions incorrectly? Could you ruin someone's credit rating by sending them the wrong bill or charging too much to their account?
Joel Coehoorn
2009-03-30 21:46:13
+1
A:
It kind of depends on the environment, ie, are you sharing code with anyone else. Consider, though, something that can be done in, eg, Smalltalk: change the meaning of the + operator. If I introduce a + function that, say, subtracts one argument from another, things are going to break in florid and unexpected ways.
Charlie Martin
2009-03-30 21:47:02
So, if I share the code, such as in an open source project, then I could introduce problems for others, yes? If I write a library that people use which changes their + operator to act like a minus operator, that's almost like a coding virus. But you're saying if I alone use the code maybe it's ok.
2009-03-30 21:58:34
Oh, I'd go farther than that. It's just something you have to be very cautious about. For example, adding methods is better than modifying the behavior of an existing method. But Rails uses it well in Ruby, for example. See InfoQ: http://www.infoq.com/articles/ruby-open-classes-monkeypatching
Charlie Martin
2009-03-31 01:31:52
Even when working by yourself, it's a very bad practice. You never know when you may come back to that code after a length of time and may forget your original intentions.
patricksweeney
2009-03-31 02:22:59
Not always, but it does have to be done with discipline. It *is* something that you should think twice about. If not more.
Charlie Martin
2009-03-31 02:51:22
The infoq article is brilliant. Just what I needed. Thanks.
2009-03-31 20:22:39
We aims to please (I'm an InfoQ editor. ;-)
Charlie Martin
2009-03-31 23:10:19
Oh, there's a lot of good examples in the book Ruby by Example.
Charlie Martin
2009-03-31 23:11:03
A:
Well, it really depends on what you mean by...
it's not good if you write some code and then someone else changes its functionality to do something else
What are the requirements? Both now and before. If the requirements have changed and the resulting set of code must change, this is called maintaining or enhancing. It is rarely I am able to meet a piece of code in the real world where "Monkey Patching" is effective, though it also relies heavily on who wrote the code, how long ago, etc. Too many variables to give a really effective answer. In short, if it is what you need to do to give your customers what they want when they want it, then it is probably a good 'ooh, better do it'. It is all about your audience.
Jeff Ancel
2009-03-30 21:51:26
+7
A:
Programming has had a slow but steady movement away from coding practices that require understanding global state to understand local behavior. Some examples:
- Gotos make it harder to reason about the flow of control because you may need to look at code far away to see how you get to a particular line.
- Global variables are also frowned upon because any part of your program can change state that affects any other part.
- Functional programming is supported because it means you don't need to worry about any state outside of your function to understand how it behaves.
Monkey patching means that there is no way to know what a line of code does without looking at every other line of code in the program. It might be useful to get something done quickly, but it will make large programs impossible to understand. Since so many large programs start as small programs, monkey patching is probably a habit you want to get out of.
RossFabricant
2009-03-30 21:59:34