Open Closed Principle — and the Fun Continues.

After hefty procrastination and cursing myself for starting a topic that requires me to write a series of blogs, I finally gave in and took out some time this weekend to write on the much-awaited topic, the Open closed principle. For those who have not read my previous article about the 1st SOLID principle please go through it here. Now, a bit about the open-closed principle — This is one principle which if followed properly can reduce development and testing efforts drastically. And there will be a meditation exercise, at last, so keep reading.😉

Uncle Bob added it to the list of design principles which we should consider to make our application ‘solid’, but he was not the one who defined it. It was originally written by Bertrand Meyer in his book Object-Oriented Software Construction. The principle says:

Software entities should be open for extension, but closed for modification.

Basically, it states that the software entities such as classes, modules, etc. should allow their behavior to be extended without modifying its source code. You might be thinking about how can we change the functionality of a class without modifying it?. Let me take you through day to day life of an intelligent developer, who will help clarify this for you.

There is a nice little restaurant which is using software, to calculate the bills their customers have to pay.

So their intelligent developer wrote the following program to ease their pain:

There is an ExtraCharges class containing all kinds of extra charges to be added on top of a bill.

There is a BillCalculator class, that calculates the bill for this nice restaurant.

This was going very smoothly until 2020 happened. This nice restaurant didn’t know what was coming for them. To help deal with the loss because of lockdown, this restaurant decided to start food delivery for the customers as no one was willing to come and dine in. Now they asked the intelligent developer to include a way to calculate the bill for the delivery orders in the software. The difference being there will be no service charge and a delivery fee has to be added.

Simple right? So this is what the intelligent developer wrote:

It works. But the issue is that the code is open for modifications and that’s what this principle asked us to avoid. But why?
Let’s see.
➛ Firstly, it changed the already working dine-in bill calculator functionality. Here it’s just a sample but in reality, this can be a huge functionality, changing which can result in the introduction of new bugs in the system.
➛ Also, the original functionality has to be tested again i.e. it has to again go through the process of unit testing, integration testing, and everything the project follows.

And the problem doesn’t end here, let’s say after COVID times ( even writing an example about post COVID times feels so good, wow!), the restaurant owner comes back and tells the developer that they are introducing buffet service in their restaurant and they want to calculate the bills for it. The customers have to pay VAT for this but no service charge. Now what? Should the intelligent developer go through the same cycle of development, changes, and testing? That doesn’t sound intelligent.

Okay, so we know the problem now. But what is the solution to this?

Let us do one thing, I will write another way to explain what the open-closed principle says and I bet you will be able to guess the solution.

You should be able to extend the behavior of a system without having to modify that system.

And Yes you guessed it right, the solution is abstract classes. ( Don’t scold me for writing this huge story and not the above line at the start. 😐 )

Now, the intelligent developer makes changes to the program in the following way.

She creates an abstract class Order which has the functionality of calculating bill via calculateBill function.

Inheriting from the Order class, she creates 2 classes DineInOrder and DeliveryOrder.

DineInOrder class:

DeliveryOrder class:

Now whenever the restaurant owner comes back with a change, the intelligent developer extends the same base class and creates a new class for different types of orders. So the code is open for extension and closed for modification. This is exactly what uncle bob wanted from us.

Let's count what we achieved by applying the open-closed principle in our software.

1. Easy Maintainability: As I said in my last article on the Single responsibility principle, the last thing you want in your application is to change an existing class on which the other classes depend and create a cascading effect on the rest of the system. Our best bet here is to make the system extensible and not to get caught in the maintenance mess.
2. Easy testing: When you extend a software entity, you just have to worry about testing the new piece of code you introduced to the system, instead of changing the existing pieces of code and testing every single functionality affected all over again.
3. Robustness: When we change an existing class every time there is a new requirement, we make it rigid and unpredictable. Not changing a class over time makes it impossible to introduce new bugs and hence makes the class more trustworthy and robust.
4. And lastly, don't make the client-side angry: Have you ever seen a famous library/framework such as spring change so much that you have to change your application code every time they release a new version? No right? Because good software doesn’t do that. They may extend the functionality or deprecate it in some cases but never backstab the client-side implementing it.

Convinced yet? Okay, time for the promised meditation — close your eyes, take some deep breathes, and think about where all have you already used this kind of design technique in your project without realizing you were following the open-closed principle. It’s like following the principles of a cult without being a part of it.

I hope the made-up example was clear and understanding this will help make the low-level design of your software interesting and effective. But a warning, don’t be a purist. When I say purist, I mean don’t get ideas in your head that your code should never change. It will change, but make it more extensible is all I am trying to say.

Let’s follow the same assignment from the previous blog and come up with a practical example of the Open-Closed principle. Please wait for my next article in the series on the Liskov Substitution principle, where I attempt to explain what Barbara Liskov said in 1987 and why does it matter to us even now, 33 years later. And don’t ask me why my examples are always related to food. 😊

Happy Learning!