Principios SOLID: Guía Práctica con Ejemplos en PHP

La orientación a objetos funciona bien cuando el proyecto es pequeño. El problema llega cuando crece, pasan varios devs por el código y lo que era limpio empieza a agrietarse por todos lados. Si has heredado un proyecto legacy sabes de qué hablo: cambias algo y se rompen tres cosas al otro lado del módulo.

Robert C. Martin reunió cinco principios bajo el acrónimo SOLID para intentar poner orden. No son leyes sagradas, pero sí una guía muy útil para evitar que tu código se convierta en un castillo de naipes.

Aplicados con cabeza, hacen que mantener y ampliar el código sea mucho menos doloroso. Vamos con los cinco.

Principios SOLID

S: Single Responsibility Principle (SRP) o Principio de Responsabilidad Única

El Principio de Responsabilidad Única establece que “una clase debe tener solo una razón para cambiar”.

Esto implica que cada clase debe tener una única responsabilidad y, esta responsabilidad, debe estar contenida en su totalidad en dicha clase.

Si una clase asume más de una responsabilidad, será más sensible al cambio.

O: Open/Closed Principle (OCP) o Principio de Abierto/Cerrado

El Principio de Abierto/Cerrado se refiere a que “una entidad debe estar abierta para su extensión, pero cerrada para su modificación”

Este principio habla de que se debe de poder extender el comportamiento de las entidades, pero sin necesitar modificar el código fuente.

Existen dos enfoques sobre este principio:

• Principio Abierto/Cerrado de Meyer.
• Principio Abierto/Cerrado polimórfico.

L: Liskov Substitution Principle (LSP) o Principio de Sustitución de Liskov

El Principio de Sustitución de Liskov establece que “las clases derivadas deben poder sustituirse por sus subclases”

Significa que los objetos tienen que poderse reemplazar por instancias de sus subtipos, manteniendo el correcto funcionamiento del sistema.

I: Interface Segregation Principle (ISP) o Principio de Segregación de Interfaz

El Principio de Segregación de Interfaz se refiere a lo siguiente: “Haz interfaces que sean específicas para un tipo de cliente, en lugar de interfaces genéricas”

Es preferible tener muchas interfaces que definan los métodos justos que forzar a implementar métodos innecesarios.

D: Dependency Inversion Principle(DIP) o Principio de Inversión de Dependencias

El Principio de Inversión de Dependencias sugiere lo siguiente: “Depende de abstracciones, no de clases concretas”

Con este principio se busca reducir las dependencias entre los módulos para poder alcanzar un bajo acoplamiento entre clases.

Conclusiones

SOLID tiene tantos defensores como detractores. A los críticos les sobra razón en una cosa: aplicado a ciegas, añade complejidad innecesaria. Una clase por responsabilidad en un CRUD de tres pantallas es sobreingeniería pura.

Pero en un sistema grande, con varios devs tocando el mismo código durante años, SOLID marca la diferencia entre poder evolucionarlo o acabar reescribiéndolo desde cero. Son buenas prácticas, no mandamientos. Úsalas donde aporten, sáltatelas donde no.

PD: Si queréis leer más sobre este tema, podéis comenzar con este enlace, o si tenéis cualquier duda podéis poneros en contacto conmigo enviando un DM por twitter.