Principios SOLID

¡Hola a todos! En este artículo, hablaré de los principios SOLID, donde detallaré el objetivo de cada principio y cómo aplicarlo.
Si te preguntas qué significa SOLID, es el acrónimo formado con la primera letra de cada principio en inglés.

¿Qué son los principios SOLID?
Son un conjunto de principios o reglas que nos ayudan a mantener nuestro código más flexible y fácil de entender. Los principios SOLID son fundamentales para el desarrollo de software orientado a objetos, evitando que tengamos que utilizar malas prácticas en nuestro código.
A continuación, describo cada principio:
Principio de Responsabilidad Única (Single Responsibility Principle)
Una clase debe tener una sola razón para cambiar, es decir, que una clase debe manejar una sola tarea para evitar que la clase cambie constantemente.
El objetivo principal es prevenir el acoplamiento de métodos para una clase y así promover la cohesión. Dividir las responsabilidades en diferentes clases nos ayuda a tener un código más limpio y entendible.
Un ejemplo con PHP
Supongamos que desarrollamos una aplicación para la gestión de tareas. En este punto, tenemos una clase llamada Tareas que representa las funcionalidades que tendrá la aplicación.
Violando el principio
La clase Tareas tiene varias responsabilidades:
- Guardar en una base de datos.
- Enviar notificaciones.
- Generar reportes.
Esto viola el principio, hace que la clase sea más difícil de entender y tiene demasiado acoplamiento de métodos.
Aplicando el principio
Separamos las responsabilidades en diferentes clases.
Principio Abierto/Cerrado (Open/Closed Principle)
Las clases deben estar abiertas a extensión y cerradas a modificación. Eso significa que las clases deben estar diseñadas para agregar una funcionalidad sin cambiar el código existente de la clase.
El objetivo de este principio es que podamos reutilizar código y, a la larga, facilitar el mantenimiento y agilidad del software.
Veamos un ejemplo: Supongamos que trabajamos con figuras geométricas donde calcularemos el área de cada figura. Tenemos una clase llamada Figura donde manejamos las figuras necesarias para el sistema.
Violando el principio
Cuando trabajamos con una estructura condicional como if-else if-else o switch, somos propensos a tener una nueva condición. En este ejemplo, puede surgir una nueva figura como el cuadrado, por lo que debemos modificar el método calcularArea().
Aplicando el principio
Para evitar estructuras condicionales, asignamos una clase por figura y las extendemos a una clase abstracta para reutilizar su código.
Principio de Sustitución de LISKOV (LISKOV Substitution Principle)
Establece que una subclase puede ser sustituida por su superclase. Este principio tiene como objetivo aplicar una herencia estricta entre las clases, es decir, cuando tenemos una clase hija, ésta debe reutilizar todos los métodos y atributos de su clase padre.
Veamos un ejemplo: Supongamos que asignamos tareas para cada desarrollador de una empresa. Como parte de lo anterior, definimos una clase Tareas como superclase y una subclase Frontend.