skip to content
Linkedin Twitter feed logo
17 June 2013

A Call To Drop “The Open Closed Principle” From The SOLID Design Principles

SLID

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 happier person :)

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, lets 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.

5Comments
leave your own
  • Kane June 17th, 2013

    Reading your article I am not sure that you are giving the OCP enough credit and perhaps are taking the principle too literally.

    I try to think realise the OCP by referencing the example given in the Los Techies eBook on SOLID (page 27): http://lostechies.com/wp-content/uploads/2011/03/pablos_solid_ebook.pdf

  • Adam Tibi June 17th, 2013

    @Kane, thank you for sharing. I did check the .pdf you’ve mentioned and read the OCP part.
    You are right, I am taking this principle too literally :) For a good reason, this is not poetry, this is computer science.
    The author is going on abstract example, the popular “shape” base class, this problem by nature requires that you think of inheritance.
    If I try to apply OCP on day to day problems within insurance or finance or another domain, I know that my infrastructure classes will probably have good chunk of inheritance and design pattern in them while my business classes (such as domain entities) don’t have any and they are subjected to change more often, this post is about business classes.

  • Boris November 27th, 2013

    Love you. Finally someone speaks about the hype around not practically proven principles and their dry shape examples from books. There is bloggers and writers who promote their bleeding edge theories, and there is us field developers who know it wont work like that in business nowadays.

  • Matthew Huntbach September 19th, 2014

    These days when I teach the OCP to students, I point out that “open for extension” should not be interpreted just as straight inheritance. The OCP should also cover code which is generalised by parameterization.

    A simple example is sorting. Of course we don’t need to write umpteen sort methods. We just have one generalised method that can be used to sort lists of anything. But actually Java’s API provides us with two. The first is for lists of objects which implements Comparable, so we could vary the way they are sorted using inheritance to override their compareTo method. The second parameterizes the comparison through taking a Comparator object as a separate parameter to do it.

  • Adam Tibi September 19th, 2014

    Matthew, so you are agreeing with me that the OCP is for frameworks (Java API) and not business.

Leave a Reply

Gravatar