Last Updated on December 28, 2024 by KnownSense
Let’s read about improving the quality, design, and maintainability of your Java applications by applying the five SOLID. principles of object-oriented design, principles that each professional Java developer should understand. We’re Going to Look at the Many Benefits of Writing SOLID code. We will also see how SOLID principles can help us transform an application from a maintenance nightmare to a robust system that is easy to change and maintain over time. It doesn’t really matter if it works for now. That project will fail sooner rather than later. This is where SOLID principles come into play. These principles are the foundation on which we can build clean, maintainable architectures.
Problems That Appear When SOLID Principles Are Not Used
There are many problems that can appear when SOLID principles are not used. Let’s look at a couple of examples. Assume we have this application with the following submodules.
We have a new change request. We need to add a new payment method. So we, as developers, go ahead and implement the change. We go to the Payment module, we make the change, we then deploy our application. After deployment, we notice that we have bugs in other subsystems. This is called code fragility. It’s a term coined by Robert C. Martin, or uncle Bob. Code fragility is the tendency of software to break in many places every time you write a change to it.
Now in same application, we have a new change request. We need to update the reports with new information. So, again, we go to the reporting module and we start to implement the change. But, unfortunately, we cannot finish it because in order to modify the reporting module, we also have to modify other parts of the system. This is another symptom of code that is not robust, and it is called code rigidity. Rigidity is the tendency for software to be difficult to change even in simple ways. Every time we have to make a modification, a cascade of other changes needs to be done before that.
Code fragility and rigidity are symptoms of high technical debt. If you encounter this in your own projects, then you most likely did not use SOLID principles when designing and architecting your application.
Technical Debt
Technical debt is the silent killer of all software projects. Therefore, it’s really important to know what it is and how we can protect ourselves against it. Although it’s quite a fuzzy term, technical debt is just a cost. It’s the cost of prioritizing fast delivery over code quality for long periods of time. Now think about and imagine you’re working on a project. For each change or bug that you need to implement, you have below choices.
It’s not realistic to think that you’ll always be able to choose code quality. Sometimes we really need to get the change into production really fast, so it’s okay to choose fast delivery sometimes. But if you always choose fast delivery, thus, you always sacrifice code quality, you’ll end up in a point where your project can no longer evolve, and that’s a really dangerous place to be in. I also think that it’s easy to understand technical debt if you look at the following charts.
We have an application that we deployed, and now we have to maintain it over a couple of years. Obviously, customers will want changes during the maintenance phase. And, obviously, those changes are going to have a financial cost associated with them. In an ideal world, that cost should be kept to a minimum. That cost should be manageable at all times. However, in projects that have high technical debt, the cost of change tends to grow over time. It grows and grows so much until it’s no longer manageable.
There is a second type of cost that comes with high levels of technical debt, and that is customer responsiveness. At the beginning of a project, we are able to respond to our customers’ needs really, really fast, and that keeps our customers very happy. However, in projects that have a high level of technical debt, our response time tends to grow larger and larger over the years. Again, we have a technical debt cost that is clearly seen in above chart. We need to take this cost into consideration because after we pass a specific point, that project is automatically a failure.
Here are some facts about technical debt. First of all, no matter how good your team is, technical debt will accumulate over time. There is nothing you can do about that. If left uncontrolled, technical debt will slowly but surely kill your project. The only thing that you can do is to try to keep it under control. You write some code for one of the sprints, and then you take some time to pay your technical debt. You apply SOLID principles, you apply design patterns, you refactor, you decouple your components, you write more unit tests, you do everything that you can to make your code less coupled and more maintainable. Then you write some more code, and then you take some time to pay the newly acquired technical debt. This cycle will go on forever. That’s how you keep technical debt under control.
The SOLID Principles
We looked at the problems of legacy systems. We understood the costs of technical debt. Now it’s time to focus our attention towards the SOLID principles. SOLID is an acronym for five software development principles that help us to keep technical debt under control. The five SOLID principles are the single responsibility principle, the open closed principle, the Liskov substitution principle, the interface segregation principle, and the dependency inversion principle. The first letter of each of these principles firms up the SOLID acronym. There are plenty of practical benefits for writing SOLID code.
- Easier to Understand: SOLID code is simple to follow and reason about.
- Faster Changes: Modifications are quick with minimal risk.
- Highly Maintainable: Ensures long-term code maintainability.
- Cost-Effective: Reduces development and maintenance costs.
- Foundation for Clean Code: SOLID principles are essential for writing clean, structured code.
Remember, SOLID isn’t everything—refactoring, design patterns, and unit testing are also essential for maintainable and adaptable code.