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:
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.
Here is some more food for thought:
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.
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.
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.
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.
A software engineer & Stack Overflow alumnus. Co-founder of Badgie. I write about software development, coding, architecture and team leadership. I also speak at conferences worldwide.
We can say that Mr. Robot is having a moment. The main character was one of the top choices and thus is perhaps the most/least realistic/annoying/inspiring portrayal of what it’s like to be a computer programmer today.Read more…