Monkeypatching and the Open-Closed Principle

Ah, the Open-Closed Principle. In static languages like C++ and Java, classes by default are Closed-Closed. In dynamic languages like JavaScript and Ruby, they are Open-Open. In Java you have to add design pattern ceremony in order to open for classes for extension; in Ruby you have to exercise discipline in order to keep them closed for modification. Yesterday Pat Maddox and I spent 80 minutes kicking the can around talking about Monkeypatching versus the Open-Closed Principle. Along the way, we talked about everything from Rebecca Black to RSpec, from Cognitive Load to watching my cat try to claw open my office window.

We’re Starting a Podcast!

Pat and I are gonna start doing this regularly. And we need a cool name for our podcast! Help us out! The giver of the winning suggestion will get something cool. Not sure what yet, but I promise it will be something cool.

But for now, just watch the rest of this post’s space for the video. Because I’m embedding it in 3… 2…

Monkeypatching and the Open-Closed Principle from David Brady on Vimeo.

5 thoughts on “Monkeypatching and the Open-Closed Principle

  1. David Brady Post author

    There isn’t. What’s worse, remember that you can duplicate a class, and the duplicate is NOT frozen, so you can unfreeze a class as easily as:

    Defrosted = Freeza.dup

    Or worse, you could just thaw Freeza directly:

    Freeza = Freeza.dup

  2. David Brady Post author

    The first half of the lesson here is “freeze” is kind of useless in Ruby. It’s not broken, but it’s so easy to circumvent that it’s almost pointless. The second half of the lesson is that freezing classes in Ruby is anathematic, sort of the opposite of idiomatic. There are all sorts of Ruby design patterns and workflows designed to keep you safe while working with unfrozen, reopenable classes.

    So, yeah. Don’t use freeze. But not because it’s broken. Freeze isn’t broken–it’s just wrong. :-)

  3. David Brady Post author

    I’ve been pacing around the O/CP lately, and this may sound like a non-answer, but while I haven’t changed my original opinion I also sort of agree with you. Not sure how to explain it… the ideas themselves, at their core, are not in direct opposition, but both of them have trivial implications that are mutually exclusive.

    This requires more thought, methinks, but in short, I think if you’re trying to write a globally universal class you’re probably going to get it wrong, whereas if you’re designing a specialized class for a specific application you have a very good chance of getting it right. Where the gears start to strip for me is when our specialized app needs a general class and wants to specialize it. Monkeypatching, inheritance, composition… we know it can certainly be done. The hard part is doing it elegantly and appropriately.

    Thanks for the comment!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s