SOLID y Laravel 5
Juanma Cabello Colaboraciones 09/09/2016
Que Laravel es uno de los frameworks más frescos y completos para PHP no cabe duda, pero eso no quita que en algunas circunstancias sintamos que no se adecua a nuestras necesidades.
Por ejemplo, Laravel no cumple al 100% el SOLID ya que hace uso de ActiveRecord en la capa de datos. Hoy te voy a explicar en que consiste el SOLID así como algunas pautas que podrás seguir en tu proyecto para ajustarlo lo máximo posible a éste interesante conjunto de principios.
¿Qué es SOLID?
El nombre SOLID es un acrónimo que viene del inglés y significa:
- Single responsibility principle.
- Open/closed principle.
- Liskov substitution principle.
- Interface segregation principle.
- Dependency inversion principle.
Básicamente son un conjunto de reglas o principios que debes seguir a la hora de desarrollar tu proyecto para conseguir una buena modularidad en el código y conseguir así hacerlo más mantenible.
Paso a explicar cada uno de éstos principios.
1. Single responsibility principle
El principio de única responsabilidad viene a decir que cada una de las clases debe de encargarse solo de una única tarea.
Cómo he dicho antes, Laravel no cumple con el SOLID debido a que usa ActiveRecord en la capa de datos; ActiveRecord permite a la clase modelo, además de ser una representación de una fila de alguna de las tablas de tu base de datos, que se puede usar para hacer consultas a la base de datos.
Desde el punto de vista de SOLID esto no es una solución correcta ya que el acceso a la base de datos debería estar en otra clase diferente y así separar la responsabilidad de las clases.
La solución es implementar el patrón repositorio en el proyecto. Básicamente se trata de usar los modelos únicamente como representación de filas de una tabla en un momento dado y usar una clase extra (el repositorio) para obtener la cantidad necesaria de modelos.
2. Open/closed principle.
El principio abierto/cerrado nos dice que las entidades de software deben estar abiertas a las extensiones pero cerradas a las modificaciones.
¿Cómo conseguir este comportamiento? Haciendo uso de interfaces bien definidas; con esto se obtienen entidades cerradas a modificaciones (las interfaces) y abiertas a extensiones (clases que implementen dichas interfaces).
3. Liskov substitution principle.
El principio de sustitución de Liskov se podría sintetizar en que una clase que herede de otra, debería de poder ser utilizada como el padre sin alterar el funcionamiento del programa.
De nuevo, haciendo uso de interfaces se puede conseguir este comportamiento; para explicarlo fácilmente, supón que tienes una clase abstracta Animal con un método darDeComer() y luego tenemos un par de clases que heredan de esta, llamémoslas Gato y Cocodrilo. Supón ahora que quieres acariciar al gato… A nadie se le ocurriría acariciar a un cocodrilo por eso no deberías implementar acariciar() en la clase Animal. La solución a este problema es crear una interfaz llamada mascotaInterface y hacer que Gato la implemente.
4. Interface segregation principle.
Con el principio de segregación de la interfaz lo que se busca es mantener las clases de nuestro proyecto desacopladas. Viene a decir que una clase no debería de tener más conocimiento del que necesita.
Dicho de otra manera, no deberías de implementar más interfaces de las necesarias en nuestras clases.
5. Dependency inversion principle.
El principio de inversión de la dependencia dice que las diferentes clases de tu proyecto deben depender de abstracciones y no de implementaciones, de tal manera que, las clases de alto nivel no tienen que prestar atención a los detalles dejando esta tarea a las clases de bajo nivel.
La manera más fácil de llegar a cumplir con este principio es hacer uso de la inyección de dependencias que, por suerte, Laravel lo lleva en su corazón.
Por poner un ejemplo más claro, imagina que tienes una clase Lector a la que se le inyecta en su constructor otra clase que debe implementar la interfaz Libro con un método formato().
Con ésta disposición, Lector no se tiene que preocupar de si el formato del libro es HTML o Markdown o lo que sea ya que se limita a llamar al método formato() de la clase pasada mediante inyección de dependencias en el momento de su construcción.
Conclusión.
Cómo puedes ver, varios de estos principios están implementados en Laravel desde el núcleo. El único nivel en el que no se cumple es en la capa de datos, pero haciendo uso del patrón repositorio (y vigilando cumplir con los demás principios) puedes adaptar tu proyecto totalmente a SOLID.
Aquí te dejo un repositorio en GitHub bastante interesante que podrás dar de alta en el composer de tu proyecto y que te permite empezar a usar repositorios rápidamente sin andar configurando demasiado.
¿Qué te parece? ¿Crees que tu proyecto se puede beneficiar haciendo uso de SOLID? ¿Lo conocías de antes? ¿Algún inconveniente al tratar de hacer uso de él? Comparte tu opinión en los comentarios.