(enlarge)
The OCP or “The Open Closed Principle” is the popular “O” from the SOLID (new tab) principles of Object-Oriented Design.
As an architect consultant working in London, I get a question about SOLID in every other interview. Since the interview usually lasts about an hour, I give an out-of-the-textbook answer; otherwise, it would run for hours. I keep my opinions to myself and I am a happy puppy.
The principle origin
First of all, let me cite the OCP origin. It was first mentioned by Bertrand Meyer (new tab), the creator of Eiffel, then resurfaced in 2000 through Robert C. Martin (Uncle Bob) in Principles and Patterns (new tab).
Quoting from Martin’s paper:
A module should be open for extension but closed for modification.
Of all the principles of object oriented design, this is the most important. […] It means simply this: We should write our modules so that they can be extended, without requiring them to be modified. In other words, we want to be able to change what the modules do, without changing the source code of the modules.
What is a module?
A module can be a class, a group of classes or a component, such as a library, that forms a feature. I will assume all of these in the discussion below.
Virtual everywhere
The moment I release a class I should not change it! I should think of all possibilities of how it can be extended, prepare all my methods to work well as virtual functions, drop the “start with the simplest thing that works” agile principle and think of the complete architecture, right now! I am going to lose my last chance of modifying it, I had better act now, before I even check in, this is the point of no return, the close to open moment, my last chance, mwahh ha ha haaaa!
Why in the hell are we writing unit tests?
If, following OCP, I always leave the existing implementation untouched and extend my module instead, then I don’t actually have to write future-proof code, because the code will not change. Every time, I will be extending existing code, and since change is the norm in software, I will keep extending until I end up with chains of hundreds of inheriting classes. I could maybe write far fewer unit tests as the logic of this module will not change!
But what happened to “Favor composition over inheritance”?
Doesn’t this contradict the OCP? Now, every time I want to change, I will wrap my existing class with another class (sort of the Decorator GoF Design Pattern) and then the original implementation would be buried under dozens of classes and can’t be reached.
Seriously, let’s drop it
Maybe this principle worked in the Waterfall era, and it might — I used the word “might” — work for third-party components or frameworks, but it doesn’t work in day-to-day business development.
Conclusion
We are used to propagating this term, no longer calling it a principle, without giving it much thought. The next time an interviewer asks me about the SOLID principles, I will ask them, “Did you mean SLID?”
I was reviewing this before posting it and the tone sounds like I am raging, but in fact I am laughing and enjoying it. I hope you share a similar joy.