Forem: Bruno Santos

How I Broke 13 Endpoints and Learned the Hard Way About SOLID’s Open/Closed Principle

Bruno Santos — Wed, 16 Jul 2025 20:34:33 +0000

As developers, we often take our systems for granted. We build, we test, and sometimes, we break things. I recently found myself in a situation where I broke not just one, but 13 endpoints, and the reason? A simple violation of a core principle of object-oriented design: the Open/Closed Principle (OCP), one of the five principles that make up SOLID.

What is SOLID?

Before I dive into how I learned about the importance of OCP, let’s briefly go over what SOLID stands for:

S: Single Responsibility Principle (SRP)

O: Open/Closed Principle (OCP)

L: Liskov Substitution Principle (LSP)

I: Interface Segregation Principle (ISP)

D: Dependency Inversion Principle (DIP)

Each principle is a guideline that helps developers design software that is easier to maintain, extend, and scale. But one principle stood out during my recent experience: the Open/Closed Principle.

Understanding Open/Closed Principle

The Open/Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. In other words, you should be able to add new functionality to a system without changing the existing code.

Why is this important?

If we don't respect this principle, we risk introducing errors into areas of the code that were previously working fine. Imagine a situation where you're working with a function that is referenced in multiple parts of your system—what happens if you change its behavior or return value? If those references expect the function to behave in a certain way, you can easily break the whole system.

My Experience

: The Case of the Broken 13 Endpoints
I was working on a system with several endpoints that relied heavily on a function to return specific data. One day, I was tasked with making a change to the return value of this function. It seemed like a simple fix—one change to improve the code.

However, I didn't stop to think about the impact this would have. This function was referenced in 13 different places across various endpoints. Without considering the OCP, I modified the function's return structure, assuming it wouldn't cause any issues.

What happened next was a mess: 13 endpoints stopped working. Each endpoint relied on the previous behavior of that function, and by changing its return value, I broke the contract that these endpoints were built on. This mistake cost a lot of time to fix and even affected the overall system stability.

How OCP Could Have Saved Me

Had I adhered to the Open/Closed Principle, the change would have been different. Instead of modifying the function's return type directly, I could have extended the function’s behavior—keeping the original functionality intact while adding the new behavior in a way that didn’t affect the existing system.

In practice, I could have:

Created a new method to handle the new behavior.

Used polymorphism to extend the functionality.

Made use of strategy or decorator patterns to change the behavior dynamically without breaking existing code.

The key takeaway here is that by thinking through the principle of open for extension, closed for modification, I could have avoided the huge impact that this change had.

Conclusion:

Learn From My Mistake
In the end, this was a painful but valuable lesson. It reinforced the importance of defending your code by respecting principles like OCP. By keeping systems open for extension and closed for modification, you avoid unintentionally breaking things that other parts of the system depend on. Always think about the bigger picture before making changes that might seem small at the time.

So, to all the developers out there—don’t be like me. Respect the Open/Closed Principle. It will save you from breaking everything when you least expect it!

The awesome layered architecture

Bruno Santos — Wed, 05 Apr 2023 07:31:36 +0000

Introduction

Hey Friends! Today i going to talk about a thing i'm learning in this latest times in a project that i'm working, that's the software architecture, it's funny because we don't care so much about this thing in the beginning and in fact it's useless when we are working with a simple personal projects, because we don't write so much code for lose ourselfs reading some files yet, but when us started to come into in a real project that has a bunch of funcionalities and code we finnally get it the meaning of all this... If the team doens't have in mind the architecture of the project, it really can to cause "headaches" in the future.

In that project that i recently started to work, we are going through this, we are working with Laravel in a big project, for standard everyone knows that technology works with MVC right?
A quick explans about what's MVC:

The "Problem" with MVC

M- means model that's for working with the database, here we create tables, write and validate any data in database.
V- means view your responsibily is show the user the informations in the application and allow he to interact with our app,
C - means controller that's responsible for receive the requests, doing the validations, operating the bussiness rules, controling the model, and sending a responsive to view.

MVC is already really good for organize your code right? But in this explanantion about this architeture, we can realize there's a side is still with a lot of work, and yes the controller is the problem here, because it's with a bunch of responsabilities, because he's the "center" of everything here, and this results in giants controllers that how more we have functions more unreadble the code there becomes, for example in the project that i'm working we have (believe in me i'm not kidding!) controllers with more of 1000 LINES!! This is crazy right? So how we can solve this problem? It's in this scenario that was create the layered architecture, the solution for the controller's problem.

What's Layered Architecture?

I think the layered architecture like a evolution of MVC because it simplely takes the controller that's the problem in this architecture and split it in more two layers that are called repository and service, in other words we had only 1 layer for this responsability and now we have three layers!

Repository: it's responsible for managing the model in database search, delete and store data.

Service: it's responsible for doing the business logic, all the validations and manipulations with the data from repository stay here.

Controller: in this pattern the controller is only responsible for receiving the request and sending a response for the view.

Using layered architure means less code in the controller and now the controller don't need to know the database and manipulate the data, it's easier for testing the backend beacause if you are receiving a bad response from controller you don't have to search in 1000 lines of code to discover where the problem is. If the problem is in the request you can find the error in the controller, if the problem is in the validation search in the service, if the server isn't saving in the database probably search for the bug in repository is the best solution, briefly you going to have less headache for solve your bugs, although it's much easier to updating your backend because you won't have repetitive code for save in a table from your database in every function that you need it in controller for example, instead that you simple can call a function in repository, here goes a quick use case:

Puting dogs in the database

In this example we going to store dogs in our database for example, first the user send a request to store a dog called Rex, first we receive the data by rquest in our controller's function, the controller takes thia request, we take the $request->name and put it in the parameter for the function dogsService->store() here we are calling the service in the controller, where we receiving thos parameter and doing the validation, we verify if already exists the same dog in the database, if the name is correct, etc.. and if everything is fine we pass this data to the function dogsRepositoritory>store(), where we going to call the table dogs in database and use the ORM to store the data there.

Conclusion

In this articles we see the importance of a good architecture like the layered architecture, it's really important for improve the aplicattion's performance, i hope you enjoy the article.