Forem: Hossein Molaei

🧱 Open/Closed Principle — One of Uncle Bob’s Fundamental Architectural Rules

Hossein Molaei — Thu, 05 Jun 2025 11:19:37 +0000

Continuing with the SOLID principles, today we will come to these two principles. To understand my point of view, you can read the Single Responsibility Principle.

📌 What Is the Open/Closed Principle?
The Open/Closed Principle, introduced by Bertrand Meyer in Object-Oriented Software Construction (1988), is defined as follows:

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

This means a software component should allow new features to be added without modifying existing code.

❓ What Does That Actually Mean in Software?
Most developers understand and apply this principle at the level of a single class or service. That’s not necessarily wrong — but that’s not true OCP either.

To properly implement OCP, you must consider it at the architectural level, across your entire project, not just individual modules. This principle helps preserve the long-term structure of your system.

🧪 Let’s Imagine an Experiment
Imagine you’re showing a page of business reports to users. Now, the user wants to export the report in a nicely formatted Word or PDF file.

Of course, we need to write new code — but here’s the real question:

How much of the existing code do we need to modify?

A well-designed software architecture aims to minimize code changes — ideally, none.

However, we know that in about 80% of cases, OCP can be satisfied this way. But we must also respect the Single Responsibility Principle (SRP) when designing.

⚙️ Separation of Concerns: Logic vs. Presentation
After implementing the reporting system, you realize it has two main parts:

Calculation
Presentation (output)
Any future changes — like adding a new export format — should be made only in the Presentation part. Thanks to this separation, we are confident that changes in one responsibility do not affect the other.

🔄 Direction of Dependency and OCP
Let’s say it again:

If Component A needs to be protected from changes in Component B, then B should depend on A, not the other way around.

In our example, we want to protect the Controller from changes in the Presenter. Therefore, the Presenter should depend on the Controller — but the Controller must not know about the Presenter.

🎯 Why the Interactor Is an OCP Champion
The Interactor is in the best position regarding OCP. Why?

It is not affected by changes in the Controller, Presenter, or even Database.
It holds the core business logic and policies, and it’s not concerned with the implementation details of other components.
If you’re still unclear, go back and look at the previous image again.
We designed our system top-down and when we needed to add a new export format, we first respected SRP, and then applied OCP.

🧩 Real-World Conflict: When OCP Is Broken
Let’s be careful:

Even though we can add new capabilities to the Interactor, if that involves changing its interface, then the Controller must change too.
👉 That would violate OCP.

However, if we only add code to the Controller, and the Interactor remains untouched, then we’ve fully respected OCP.

✅ Final Conclusion
We can conclude:

Designing the system from large to small helps protect lower-level components from unnecessary changes.

And in approximately 80% of use cases (this is an intuitive figure), OCP can be achieved.

Whenever you manage to fully respect OCP, you’ve likely designed an ideal system.

_Author: Hossein Molaei
Translation from Persian to English by artificial intelligence

ref: Clean Architecture (Robert C Martin)_

SOLID Principles from the Perspective of Robert C. Martin

Hossein Molaei — Mon, 26 May 2025 08:54:14 +0000

Single Responsibility Principle (SRP)

According to Uncle Bob, the Single Responsibility Principle (SRP) can only be applied correctly when you clearly identify the system’s actors.

“A module should be responsible to one, and only one, actor.”

Sometimes, the best way to prove a principle is to explore what happens when it’s violated.

Let’s look at a common example:

The calculatePay() method is defined and used by the Accounting department, which reports to the CFO.
The reportHours() method is used by HR, reporting to the COO.
The save() method is managed by DBAs, under the CTO.

At first glance, it might seem that the class follows SRP. After all, each method has a single job. But in reality, this is a clear violation of SRP. Why?

Because placing these three methods in a single class connects three different actors — meaning changes from one team might affect the others unintentionally.

⚠️A Real-World Scenario
Imagine both calculatePay() and reportHours() share a helper method called regularHours().

This method might seem like a single responsibility function. But what happens if the accounting department wants to change how overtime is calculated? They modify regularHours() to meet their needs.

But here’s the issue: HR is also using regularHours() — and they’re not aware of the change. The accounting team runs their tests and everything seems fine. But a few weeks later, HR starts complaining about inaccurate reports.

By the time the issue is discovered, the organization may have already suffered from incorrect data and misinformed decisions.

SRP tells us that this could’ve been avoided by separating responsibilities by actor.

👨‍💻 Parallel Development Chaos
Now imagine two developers working on this class:

One updates calculatePay() for the finance team.
The other updates reportHours() for HR.
When it’s time to merge, they run into conflicts — despite modern version control tools being quite advanced, merge conflicts in shared classes are still risky and can introduce subtle bugs.

✅** A Better Design**
One practical solution is to separate data from behavior. Instead of one large Employee class, you split responsibilities:

PayCalculator handles payroll logic.
HoursReporter manages working hours.
EmployeeRepository deals with persistence.
All of these classes can access a shared EmployeeData structure — a plain data holder without any business logic.

Each class contains only the source code necessary for its own responsibility. They are not aware of each other, reducing the chance of accidental overlap or unintended coupling.

💡 Facade to the Rescue
You might object: “Now I have three classes to instantiate and track!”

That’s fair. A common approach here is to use the Facade Pattern — a single class that hides the complexity of the subsystem and offers a simplified interface to the outside world.

So your application deals with one class, but under the hood, responsibilities remain separated.

🧠 Final Thoughts
The Single Responsibility Principle should be enforced not just at the method level, but throughout the entire architecture — from the top down.

Every actor in the system should have a corresponding class, with focused methods that serve only that actor’s needs. This leads to a system that is easier to scale, test, and maintain.

SRP isn't about writing fewer classes — it's about writing better ones.

Taken from the book Clean Architecture by Robert C. Martin

Translated by artificial intelligence from Persian to English.
Author : Hossein Molaei