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.

Closed at the front, open 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


Hi, I'm Marco Cecconi. I am the founder of Intelligent Hack, developer, hacker, blogger, conference lecturer. Bio: ex Stack Overflow core team, ex Toptal EM.

Read more

Newest Posts

What can Stack Overflow learn from ChatGPT?

Stack Overflow could benefit from adopting a using conversational AI to provide specific answers

Read more
Fan mail

Multiple people with my name use my email address and I can read their email, chaos ensues!

Read more
Intelligent Trip

After years of building, our top-notch consultancy to help start-ups and scale-ups create great, scalable products, I think it is high time I added an update to how it is going and what's next for us.

Read more
Guest blog: Building, in partnership with communities by Shog9

A lesson in building communities by Stack Overflow's most prominent community manager emeritus, Shog9

Read more
Can you migrate a company from on-premise to remote-only?

Some lessons learned over the past 8 years of remote work in some of the best remote companies on the planet

Read more

Gleanings

You Are Not Google
Ozan Onay • Jun 07, 2017

Software engineers go crazy for the most ridiculous things. We like to think that we’re hyper-rational, but when we have to choose a technology, we end up in a kind of frenzy 

Read more…