Say "No" to the Open/Closed pattern

The open/closed principle is the second of the five SOLID principles. The best place to start to try and understand it is probably Uncle Bob's article on it, but you can also take a look at the Wikipedia page or read about it in Bertrand Meyer's "Object-Oriented Software Construction" book.

The canonical description is

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

The best critique you can find is the one by the amazing Jon Skeet. I won't repeat the points he makes, which I find completely correct and subscribe completely to, but in summary:

• It's not clear what "open" and "closed" mean
• It's not clear what exactly should be "open" or "closed"

This is enough to make it a bad principle (or law, or idea). Why? Because it guarantees that people will all have different interpretations of it and won't be able to apply it consistently. Because it is not effective. And because it's suspiciously like a mullet: business at the front, party at the back.

^source

Here is some more food for thought:

Not a principle

It's a little more than a pattern, albeit it's described as a principle. Equally, it's not a law, or a guideline, or anything similar.

Sometimes -- better, normally -- the simplest thing is changing a class, not using inheritance, and simple code is likely better, more understandable and easier to maintain code. Not all applications are super enterprise-y behemoths, remember? Even then, in the world of humongous enterprise integration projects, I am prepared to bet that using it in most cases would not be necessary or advantageous.

Not about design

This "principle" describes how to handle change -- don't change the source code, but write new classes -- but it's presented and understood as a design principle. The consequence of that is violating YAGNI. Designing imagining change is, well, statistically going to fail, unless support for change is part of the requirements... nobody is good at predicting the future. If change never happens, we just added extra complexity for no reason. If change happens, is it the same as we imagined? Because if it isn't, we have a system which is harder to change because of the extra complexity.

Arbitrary

Imagine a code base where, as requirements change people actually changed classes instead of sub-typing! Shocking, eh? Probably, not very much. People do it all the time. Consistently applying OCP is clearly not what people do, which in turns means that it's totally arbitrary when to apply it.

In fact, the OCP does not say "Modules should be open/closed when ...". I can only interpret this as "always" -- but if not "always", there's no guidance on where it is appropriate to apply it -- which is, I guess, the criticism that most patterns get in general.

Addendum

I wrote this a couple of weeks back but I noticed some new content on Martin's site. Apparently, according to Martin, OCP applies to plugin systems. Now -- I can see that if you have a framework with plugins, you can add a plugin to add a functionality, but it's equally clear that frameworks with plugins are not the norm, are not a preferred way of designing applications in general.

In conclusion, just say no to OCP, there's little to gain, in my opinion.

(comments on HN)

follow me on twitter