Introduction

This content will follow a new approach to publications that I aim to address this year.

Briefly (or long), in this new series of contents I aim to disseminate some scars of some concepts, experienced in practice in the industry by me.

Without further ado, this time I’m going to squeeze a certain corner case from the Open-Closed Principle, the famous O from SOLID.

History

I was working on decomposing a class that had around 2200 lines of code.

One of the first points observed is that the class contained around 90 methods, of which only 15 were exposed through a public interface (~15%).

This symptom indicates that the class has low cohesion. Your responsibilities are no longer objective.

As I see it, this opens up a vision for an action strategy: Depending on the intent of the class, I can use something close to the Facade design pattern to keep its interface with client code intact, while working on its decomposition behind the protocol.

Lucky for me, the class abstracts contact with a third-party API, making it clear the existence of a conformist dependency relationship.

Another point that would give eyes to another symptom would be the lack of security in the development and maintenance of features.

The team followed pragmatically, executing the creation of characterization tests as a way of guaranteeing the functioning of what already existed, however, even so, the development was not safe.

Thus, an output with a quick result would be the applicability of the Open-Closed Principle. By writing characterization tests, we would reveal delegation points and extend behaviors effectively.

As said, we would have a quick result and a sustainable action plan.

However, I am faced with a dilemma: In a system with very low cohesion, approaching methods and extending them would lower their cohesion even further.

As we extended behaviors, we would be adding more distinct responsibilities for other methods that shouldn’t be there. And therein lies the double-edged sword.

The applicability of the Open-Closed Principle in low cohesion classes results in a direct breach of the Single Responsibility Principle.

At first, we would be advancing fast, but in the view of the system as a whole, we would contribute to the worsening of the project.

Finally, the output was a little longer: Outlining plans to identify and add responsibilities as quickly as possible (I won’t touch on this subject, it’s for another publication), raise some scenarios and carry out the proposal.

In this way, we would be able to create isolated components with well-defined responsibilities, supported by the Facade strategy, using the existing class protocol.

After the land was fixed, we would be free to continue with the development of features through the extension.

Build composable frontend and backend

Don’t build web monoliths. Use Bit to create and compose decoupled software components — in your favorite frameworks like React or Node. Build scalable and modular applications with a powerful and enjoyable dev experience.

Bring your team to Bit Cloud to host and collaborate on components together, and greatly speed up, scale, and standardize development as a team. Start with composable frontends like a Design System or Micro Frontends, or explore the composable backend. Give it a try →

Learn More