问题
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?
回答1:
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.
回答2:
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?
回答3:
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.
回答4:
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.
来源：https://stackoverflow.com/questions/699152/looking-for-a-concrete-example-of-whats-wrong-with-monkey-patching