%402x.svg){kind=icon}
In software development, one of the biggest challenges is keeping the code clean, maintainable, and scalable. This is where SOLID principles come into play. These principles, devised by Robert C. Martin (known as “Uncle Bob” within the guild), are essential for developers who want to write quality code. If you are interested in Clean Code, Domain-Driven Design (DDD) or any current of good practices, these principles are the pillars.
The Single Responsibility Principle (SRP) says that a class should have only one reason to change. In other words, each class should focus on a single task or functionality. This makes it easier to maintain and reuse the code. The first change that is usually made to apply this principle is that the controllers, instead of having all the CRUD in the same file, each action is separated into different controllers. One trick I use to know that controllers or services have only a single function or responsibility is that they only have an invoke () as a public method, in addition to the constructor.
The Open/Closed Principle (OCP) states that a software entity (class, module, function, etc.) must be open for extension but closed for modification. This means that we should be able to add new functionality without changing existing code. This is primarily achieved through inheritance and the use of interfaces.
A good way to apply this principle is with the repository pattern, in which we always declare an interface.
The Liskov Substitution Principle (LSP) states that the objects of a derived class must be able to replace the objects of their base class without altering the proper functioning of the program. This principle ensures that derived classes can be used instead of their base class without problems.
The Interface Segregation Principle (ISP) proposes that users of an interface should not rely on interfaces that they do not use. Instead of having a large interface, it's better to create smaller, more specific interfaces. This way we avoid implementing methods that we don't need.
The Dependency Inversion Principle (DIP) states that high-level classes should not depend on low-level classes, both should depend on abstractions. In addition, abstractions should not depend on details; details should depend on abstractions.
This principle is very useful when it comes to testing and mocking services, so we ensure that the test only tests the class we are testing on and not its dependencies.
Having a service container can make a difference when it comes to applying it, nowadays any framework already offers a service container, for example, in Symfony, we can automatically pass as a parameter in a constructor of a service, another service and it will automatically inject it.
SOLID principles are fundamental to writing code that is easy to maintain, scalable, and robust. Implementing these principles requires practice and discipline, but the long-term benefits justify the effort. In addition, SOLID is the basis for implementing Clean Code, Hexagonal Architecture or DDD, among others.
%402x.svg){kind=icon}