Let’s Learn SOLID — Open/Closed Principle
If you asked me what’s the most confusing principle in the SOLID principles, without any hesitation I’d say it’s the Open/Closed Principle. But why I’m saying that with much confidence? To make my point, we just only need to focus on the definition of the Open/Closed principle.
Meaning of the Open/Closed Principle
The Open/Closed principle states that a specific functionality should be open to extensions and closed to modifications.
Wait, what? How I’m supposed to extend the functionality when it’s closed for modification? That’s what I was saying at the very beginning. However, as an old saying, every problem has a creative solution. So, first, let’s consider a case that violates the Open/Closed Principle and next let’s see how the human nature of problem-solving and knowledge of OOP going to help us in such cases.
Violation of the Open/Closed Principle
Imagine that we have a library management system, in which the main entity is Document and yet have the Newspaper and Book sub-entities as well. So, the UML diagram for this scenario would look as follow.
Suppose now we have a need to display the information of each Document using a generic function called printDocument. Since both Newspaper and Book subclasses have different identifications number schemas we need to write print statements for each class as below.
So it’s pretty cool and neat, isn’t it? But think about having 10s of this kind of utility functions that work with the Document class and its sub-classes, then you need to write if statements and repeat your code for each subclass. And also worse come to worse, what if you need to add another Journal subclass or remove the existing Newspaper subclass after writing all these utility functions? Needless to say, you have to write if statements for all those utility classes to handle the new Journal class, which means the extendability of our code utterly fails along with high impact modifications. So that means we are violating the Open/Closed Principle utterly.
Let’s Fix the Code
Now as you can see, we only need to modify the printDocument function only when a new subclass is added or removed. So what if we could implement and overrides the printDocument function inside of the parent class and each subclass as like follow.
I know what you are thinking right now, yeah obviously the lines of codes and boilerplate codes have been increased. Even though there are so many boilerplate codes yet the printDocument function remains simpler and manageable. If you analyze the code carefully, you can see that since there’s no impact from the subclasses to the printDocument function, we don’t need to do any changes to the printDocument function when we add or remove subclasses to the Document superclass.
This is just one common violation of the Open/Closed Principle that most programmers run into, but there are some other violations regarding this principle as well. Yet the basic method of identifying a violation regarding the Open/Closed Principle remains the same. In most cases that could be a violation of the Open/Closed Principle if your code contains a specific statement(s) that needs to repeat or modify once a functionality of your code is getting extended.
One thing to keep in your mind is never to be hesitated to use design principles in your code at the very beginning of your projects. Because at the beginning of the project you’d see using design principles as just a lot of boilerplate code but you will only realize the value of them once your codebase grew into 1000s lines of code lines.
So, let’s meet with another article 👋
