SOLID es un acrónimo acuñado por Robert C.Martin para definir los cinco principios básicos de la programación orientada a objetos: Single responsibility, Open-closed, Liskov substitution, Interface segregation y Dependency inversion. SOLID tiene bastante relación con los patrones de diseño.
Estos principios no dejan de ser una filosofía, una manera de hacer las cosas que a la larga, hará que tus proyectos sean más estables, mantenibles, robustos y escalables en el futuro. Muchas veces ni los plazos ni el presupuesto te dejan tiempo para aplicar todas las buenas prácticas que se te puedan ocurrir, pero aplicar esos principios debería ser un MUST en todos tus proyectos.
Los buenos programadores usan sus cerebros, pero unas buenas directrices nos ahorran de tener que hacerlo en cada caso
Francis Glassborow
Que levante la mano el que alguna vez no ha hecho una ñapa o se ha visto obligado a salir con lo puesto por cumplir con un plazo. Si miras al futuro, adivinarás que no es bueno, a veces también hay que educar al cliente y hacerle ver que hay cosas que hacerlas bien lleva tiempo, ergo cuestan más dinero.
Aplicando estas guías o directrices eliminarás problemas en un futuro, tendrás todo mejor organizado, y evitarás refactorizar clases para adaptarlas a nuevas funcionalidades futuras.
S: Single Responsability Principle (SRP)
El principio de responsabilidad única se basa en que cada clase o método sólo debe hacer una cosa, sencilla y concreta. Si un objeto tiene un sólo cometido, éste será más fácil de mantener.
A Class should have only one reason to change
Robert C. Martin
Si un módulo o una clase agrupa funcionalidad muy dispersa, como por ejemplo la típica clase de utilidades que se utiliza a modo cajón de sastre, se dice que su cohesión es baja. Por el contrario, tiene una única responsabilidad, su cohesión es alta.
Una alta cohesión es deseable para mejorar características de nuestro código como la mantenibilidad y la reusabilidad.
Se viola este principio cuando por ejemplo en un mismo método se mezcla la lógica de negocio con la lógica de presentación, para ésto es mejor dos clases distintas, cada una para manejar su responsabilidad.
Otro ejemplo muy bueno es la típica función para leer los datos de un JSON, e importarlos a tu base de datos. Si hacemos todo el proceso en una única función o método, estaremos inclumpliendo SRP. Lo ideal sería que dividas la clase en diferentes métodos:
- Un método que obtenga el JSON
- Otro que compruebe que la estructura es la que deseamos
- Al recorrer el JSON, un método que compruebe si el dato ya existe en nuestra BBDD
- Otro que si existe actualiza, de lo contrario lo crea
De este modo, cada método tendrá una única responsabilidad, y será más fácil realizar test unitarios
O: Open / Closed Principle
El segundo principio SOLID es el Open/Closed. Está estrechamente relacionado con el SRP que vimos en el punto anterior.
El principio Open/Closed dice que una clase/método debe estar abierto a extensiones pero cerrado a modificaciones.
Software entities (classes, modules, functions, etc…) should be open for extension but closed for modification
Bertrand Meyer
Probablemente represente el mayor desafío cuando te pones a desarrollar una clase o método: pensar en el mañana. ¿Te ha pasado alguna vez que te toca modificar algo que desarrollaste hace unos meses, y que al modificar el código de un método afecta a otra parte de la aplicación sin darte cuenta?
Si el día de mañana el cliente solicita un nuevo requisito para algo que ya tienes desarrollado, si tienes en cuenta este principio, el comportamiento de esa clase debería ser extendido, nunca modificado. En caso contrario la probabilidad de que te encuentres con daños colaterales es muy alta.
L: Liskov Substitution Principle
Este principio recibe el nombre (más bien el apellido) de la persona que lo acuñó: Barbara Liskov.
Subtype Requirement: Let φ(x) be a property provable about objects x of type T. Then φ(y) should be true for objects y of type S where S is a subtype of T.
Barbara Liskov
Este principio trata sobre que los objetos de un desarrollo deberían ser reemplazables por instancias de sus subtipos sin alterar el correcto funcionamiento del desarrollo. Dicho de otro modo: cualquier subclase debería poder ser sustituible por la clase padre.
De este modo, nuestros desarrollos mantendrán una integridad. De lo contrario, será un chochal del que sólo tendremos constancia nosotros y luego el día de mañana lo heredará otra persona o tu yo del futuro, y lo que vendrá a continuación te suena, ¿no?
I: Interface Segregation Principle
Este principio trata sobre algo parecido a SRP. Es mejor definir una serie de métodos abstractos a través de una serie de interfaces para que implementen nuestras clases.
Cada interface tendrá una única responsabilidad. Es preferible tener muchas interfaces que contengan pocos métodos que tener un interface con muchos métodos.
Clients should not be forced to depend on methods they do not use
Robert C. Martin
El objetivo no es otro que poder reutilizar estas interfaces en otras clases. Cada clase implementará las interfaces que necesite y use, ninguna más. No contendrá métodos que no utilice. De nuevo con el objetivo de aplicar sentido común y no ensuciar una clase con métodos o propiedades que no se utilizan.
D: Dependency Inversion Principle
El objetivo de este principio es conseguir desacoplar las clases de nuestro desarrollo. Que una clase pueda funcionar por sí sola sin depender de otra. Es difícil, pero en todo diseño de software al final suele existir un acoplamiento, pero hay que evitarlo en la medida de lo posible. Un sistema altamente acoplado es muy difícil de mantener.
High-level modules should not depend on low-level modules. Both should depend on abstractions
Robert C. Martin
Abstractions should not depend upon details. Details should depend upon abstractions
El objetivo es conseguir que una clase interactúe con otras clases sin que las conozca directamente.
¿Se puede aplicar SOLID a WordPress?
Si. Es recomendable siempre seguir buenas prácticas a la hora de crear tus plugins y temas. SOLID no es más que unos principios, unas recomendaciones, para que tu desarrollo esté bien estructurado y organizado, y sea mantenible y escalable en el tiempo.
Es sólo una manera de hacer (bien) las cosas. La vida real (clientes, deadlines…) a veces no te permite disponer de todo el tiempo que te gustaría para hacer tus desarrollos, pero es importante adoptar esta filosofía.
Puede que también te interese
