%402x.svg){kind=icon}
En el desarrollo de software, uno de los mayores desafíos es mantener el código limpio, mantenible y escalable. Aquí es donde los principios SOLID entran en juego. Estos principios, ideados por Robert C. Martin (conocido como "Uncle Bob" dentro del gremio), son esenciales para los desarrolladores que queremos escribir código de calidad. Si te interesa el Clean Code, el Domain-Driven Design (DDD) o cualquier corriente de buenas prácticas, estos principios son los pilares.
El Single Responsibility Principle (SRP) dice que una clase debería tener una única razón para cambiar. En otras palabras, cada clase debe centrarse en una sola tarea o funcionalidad. Esto facilita el mantenimiento y la reutilización del código. El primer cambio que suele hacerse para aplicar este principio, es que los controladores, en lugar de tener en el mismo archivo todo el CRUD, cada acción esté separada en diferentes controladores. Un truco que utilizo para saber que los controladores o servicios tienen solo una única función o responsabilidad, es que solo tenga como método público un invoke(), además del constructor.
El Open/Closed Principle (OCP) establece que una entidad de software (clase, módulo, función, etc.) debe estar abierta para su extensión pero cerrada para su modificación. Esto significa que deberíamos poder agregar nueva funcionalidad sin cambiar el código existente. Esto se logra principalmente mediante la herencia y el uso de interfaces.
Una buena forma de aplicar este principio es con el patrón repositorio, en el que siempre declaremos una interfaz.
El Liskov Substitution Principle (LSP) establece que los objetos de una clase derivada deben poder sustituir a los objetos de su clase base sin alterar el correcto funcionamiento del programa. Este principio asegura que las clases derivadas puedan ser usadas en lugar de su clase base sin problemas.
El Interface Segregation Principle (ISP) propone que los usuarios de una interfaz no deben depender de interfaces que no utilizan. En lugar de tener una interfaz grande, es mejor crear interfaces más pequeñas y específicas. Así evitamos la implementación de métodos que no necesitamos.
El Dependency Inversion Principle (DIP) establece que las clases de alto nivel no deben depender de clases de bajo nivel, ambas deben depender de abstracciones. Además, las abstracciones no deben depender de detalles; los detalles deben depender de abstracciones.
Este principio es muy útil a la hora de hacer testing y mockear los servicios, así nos aseguramos que el test solo prueba la clase sobre la que hacemos test y no sus dependencias.
Tener un contenedor de servicios puede marcar la diferencia a la hora de aplicarlo, hoy en día cualquier framework ya ofrece un contenedor de servicios, por ejemplo, en Symfony, automáticamente podemos pasar como parámetro en un constructor de un servicio, otro servicio y automáticamente lo inyectará.
Los principios SOLID son fundamentales para escribir un código que sea fácil de mantener, escalable y robusto. Implementar estos principios requiere práctica y disciplina, pero los beneficios a largo plazo justifican el esfuerzo. Además SOLID es la base para implementar Clean Code, Arquitectura hexagonal o DDD, entre otros.
%402x.svg){kind=icon}