🏛️ ¿Qué son los principios SOLID?
Los principios SOLID son buenas prácticas para escribir código de programación que sea fácil de entender, mantener y extender.
En el entorno profesional del software añadir funcionalidades nuevas puede ser un auténtico drama si el código no está bien planteado desde un inicio. Los principios SOLID sirven como guía para intentar solventar este problema.
¿Y qué significa SOLID? ¡Lo he leído como 5 veces!
SOLID es un acrónimo que representa los principios que a continuación vamos a ver.
🧩 Single Responsibility Principle
El SRP (Principio de Responsabilidad Única) dice que cada parte del código, por ejemplo, una clase, debe tener una única responsabilidad o razón para cambiar.
Una clase sólo debe tener una razón para cambiar, esto quiere decir que sólo debe tener una tarea.
Por ejemplo, una clase que se encarga de calcular el total de una factura, si además también tiene una función que “imprime” esta factura incumpliría el SRP ya que está haciendo dos cosas distintas.
Para cumplir el SRP debemos separar estas diferentes funcionalidades en clases distintas.
🔓 Open/Closed Principle
Las entidades deben estar abiertas a la extensión pero cerradas a la modificación.
Es decir, debes poder añadir funcionalidades nuevas pero NO modificar el código existente.
- Abierto: Puedes agregar nuevas funcionalidades sin modificar el código que ya existe, por ejemplo derivando clases o implementando interfaces.
- Cerrado: No debes modificar el código que ya está en funcionamiento para agregar nuevas funcionalidades. Al cumplir esto te aseguras de que la funcionalidad actual se mantenga estable.
Por ejemplo para cumplir este principio Open/Closed tendríamos que poder crear nuevas clases extendiendo de una clase base sin tener que modificar la clase original. Esto evitaría fallos en el código que ya está funcionando y facilita el mantenimiento ya que la clase original está intacta.
🔄 Liskov Substitution Principle
Las partes intercambiables deben poder funcionar correctamente cuando se reemplaza una por otra.
¿Qué significa esto?
Que cualquier instancia de una clase derivada debe poder usarse en el lugar de una instancia de su clase base sin alterar el correcto funcionamiento de la aplicación.
✂️ Interface Segregation Principle
El Principio de Segregación de Interfaces (ISP) dice que es mejor tener muchas interfaces pequeñas y específicas, en lugar de una grande que haga de todo.
Así, las clases solo implementan lo que realmente usan y no tienen que cargar con métodos que no usan.
Un ejemplo rápido sería crear una interfaz para un empleado de un restaurante de comida rápida, se podrían implementar en ella los métodos tomar pedidos, cobrar, preparar la comida, entregar pedidos a domicilio…
Pero salta a la vista que un solo empleado no debería hacer todas esas tareas, por lo que quedaría una interfaz sobredimensionada con métodos que en algunos casos no se van a utilizar.
Por ello la mejor opción es crear intefaces con solo los métodos que realmente se van a utilizar.
🏗️ Dependency Inversion Principle
Este principio dice que en lugar de inyectar dependencias con un tipo concreto se deben inyectar con abstracciones (interfaces o clases abstractas base).
Un módulo de alto nivel no debe depender de módulos de bajo nivel, si no de abstracciones (interfaces o clases abstractas).
Es decir, Inyectar como dependencia la clase Coche que implementa la interfaz Vehículo no sería lo más correcto, si no que sería mejor inyectar como tipo de dependencia una instancia que implemente la interfaz Vehículo.