The OCP or “The Open Closed Principle” is the popular “O” from the SOLID principles of Object-Oriented Design.
As an architect consultant working in London, I get a question about SOLID, every other interview. As usually the interview is about an hour, I answer the question by an out-of-the-textbook type of answer, otherwise, the interview will span for hours. I keep my opinions for myself and I am a happy puppy.
The principle origin
First of all, let me cite the OCP origin. This is first mentioned by Bertrand Meyer the creator of Eiffel then surfaced in 2000 by Robert C. Martin (Uncle Bob) in Principles and Patterns.
Quoting form 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 “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 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 every time I want to leave existing implementation, following OCP, without changing it and extending my module, then I don’t actually have to write future proof code as the code will not change, every time I will be extending existing code and as the norm in the software in change, I will keep extending and I will be reaching hundreds of inheriting class chains. I could maybe write much less unit tests as the logic of this module will not change!
But what happened to “Favour composition over inheritance”?
Doesn’t this contradict with 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 covered with 10s of classes and can’t be reached.
Seriously, let’s drop it
Maybe this principle has worked in the Waterfall era, or it might, I used the term “might”, work in 3rd party components or frameworks, but it doesn’t work in the day-to-day business development.
Conclusion
We are used to propagate this term, no longer calling it a principle, without giving it much thoughts. The next time an interviewer asks me about the SOLID principles I will ask him/her did you mean SLID?
I was reviewing this before posting it and the tone looks like I am raging, but the fact is, I am laughing and enjoying it. I hope you share me a similar joy.