Monkey-patching Vs. S.O.L.I.D. principles?

Question

I\'m slowly moving from PHP5 to Python on some personal projects, and I\'m currently loving the experience. Before choosing to go down the Python route I looked at Ruby. Wha

Answer 1

My first thought is that monkey-patching violates OCP, since clients of a class should be able to expect that class to work consistently.

Answer 2

You may find enlightening this discussion about Ruby's open classes and the Open-Closed Principle.

Even though I like Ruby, I feel monkey-patching is a tool of last resort to get things done. All things being equal, I prefer using traditional OO techniques with a sprinkle of functional programming goodness.

Answer 3

Monkey patching is not ruby-explicit, its done all over javascript too, with negative (IMO) effects.

My personal opinion is monkey patching should only be done to

a) Add functionality to an old version of a language which is available in the new version of the language which you need.

b) When there is no other "logical" place for it.

There are many many easy ways to make monkey patching really awful, such as the ability to change how basic functions such as ADDITION work.

My stance is, if you can avoid it, do so.

If you can avoid it in a nice way, kudos to you.

If you can't avoid it, get the opinion of 200 people because you probably just have not thought about it hard enough.

My pet hate is mootools extending the function object. Yes, you can do this. Instead of people just learning how javascript works:

setTimeout(function(){ 
    foo(args); 
}, 5000 ); 

There was added a new method to every function object, ( yes, im not joking ) so that functions now have their own functions.

foo.delay( 5000 , args );

Which had the additional effect of this sort of crap being valid:

foo.delay.delay( 500,  [ 500, args ] ); 

And on like that ad infinitum.

The result? You no longer have a library, and a language, your langauge bows to the library and if the library happens to be in scope, you no longer have a language, and you cant just do things the way that they were done when you learn the language, and instead have to learn a new subset of commands just to not have it fall flat on its face ( at the cost of excessive slowdowns! )

_{may i note that foo.delay also returned an object, with its own methods, so you could do}

x = foo.delay( 500, args ); 
x.clear(); 

and even

 x.clear.delay(10); 

which may sound overly useful, ... but you have to take into consideration the massive overhead used to make this viable.

 clearTimeout(x); 

SO HARD!

(Disclaimer: its been a while since I used moo, and have tried to forget it, and function names/structure may be incorrect. This is not an API reference. Please check their site for details ( sorry, their API reference sucks! ))

Answer 4

Monkey-patching is just plain wrong, IMHO. I've not come across the open/closed principle you mention before, but it's a principle I've long held myself, I agree with it 100%. I think of monkey-patching as a code-smell on a larger scale, a coding-philosophy-smell, as it were.

Answer 5

In my eyes, monkey-patching is one form of AOP. The article Aspect-Oriented Design Principles: Lessons from Object-Oriented Design (PDF) gives some ideas of how SOLID and other OOP principles can be applied to AOP.

Answer 6

Mokeypatching is generally wrong. Create a proper subclass and add the methods.

I've used monkeypatching once in production code.

The issue is that REST uses GET, POST, PUT and DELETE. But the Django test client only offers GET and POST. I've monkeypatched methods for PUT (like POST) and DELETE (like GET).

Because of the tight binding between Django client and the Django test driver, it seemed easiest to monkeypatch it to support full REST testing.