SOLID — Open Closed Principle

Continuing our series on SOLID, let’s move on to the second letter, “O”. If you haven’t read the previous article on Single Responsibility, please go back and read it. The Open Closed principle works in a very clear and simple way, helping us keep the application as “Plug and play” as possible, meaning it’s easy to connect something to a module but difficult or unnecessary to alter the module itself, thus removing interdependence between modules.

The famous Robert Martin’s Clean Architecture book explains the Open Closed principle extremely simply in one sentence, and I’d like to share it with you!

“A software artifact should be open for extension, but closed for modification.”

But how do we achieve this? Basically, we start by using Single Responsibility to separate the responsibilities of the application’s actors. After each part of the application has its proper isolated role in a block or structural entity, we can start thinking about “Plug and play”. For example, consider the payment checkout system of an application. We can create a “core” with clear rules and well-defined interfaces with parameters regarding transaction status, customer tax data, and other necessary data. But imagine now that you want to add a new type of non-credit card payment. Without considering single responsibility and open closed, you would automatically need to alter the payment entity code. After making that change, let’s say a new update is requested by management, and from now on, the development team also needs to integrate Bitcoin payments. Months later, Ethereum. Ultimately, without a modular architecture truly focused on each new payment method reading data from the payment module while the payment module has no idea what Bitcoin is, the application is doomed to decline and fail. My advice is:

“The high-level components of the application should be protected from changes in low-level elements.”

Essentially, it’s the power of having a drill and not needing to disassemble it and change parts every time you need to change a drill bit. I think that’s clear, isn’t it?

And that’s it!

But what about code, diagrams, nothing? I don’t think it’s necessary to take this post to that level. That varies case by case and system by system. Things adapt to the principle, not the other way around. Every time you integrate with some kind of service, API, or similar, remember this! Don’t let a new integration interfere with what already works, has been tested, and approved. Create interfaces and “contract” structures so that nothing passes through them without being expected, and connect new functionalities as if they were drill bits being changed in a drill.

Agree? Disagree? Liked it? Leave your contribution by liking or commenting :).