El dia de hoy les quiero explicar un concepto muy importante cuando de diseño y desarrollo de aplicaciones hablamos.
Se trata de los principios SOLID :
S single Responsability
Una clase una responsabilidad
O open/Closed Principle
Organizar el código modularmente
“Las entidades: clases, módulos, interfaces, etc. deben estar abiertas por extensión pero cerradas para modificación”
L liskov substitution
Deberíamos poder usar una clase
hija para sustituir a una clase padre
sin obtener errores.
I interface segregation
Si una interfaz crece demasiado
pierde su objetivo y viola el primer
principio
D dependency Inversion
Depende de una abstracción no de
algo concreto
Entre los objetivos de tener en cuenta estos 5 principios a la hora de escribir código encontramos:
- Crear un software eficaz: que cumpla con su cometido y que sea robusto y estable.
- Escribir un código limpio y flexible ante los cambios: que se pueda modificar fácilmente según necesidad, que sea reutilizable y mantenible.
- Permitir escalabilidad: que acepte ser ampliado con nuevas funcionalidades de manera ágil.
En definitiva, desarrollar un software de calidad.
En este sentido la aplicación de los principios SOLID está muy relacionada con la comprensión y el uso de patrones de diseño, que nos permitirán mantener una alta cohesión y, por tanto, un bajo acoplamiento de software.
Arriba vimos un pequeño overview de los principios de SOLID, ahora veremos mas a profundidad cada uno de ellos, empecemos :
1. Principio de Responsabilidad Única
“A class should have one, and only one, reason to change.”
“Una clase debe tener una, y solo una, razón para cambiar”.
La S del acrónimo del que hablamos hoy se refiere a Single Responsibility Principle (SRP). Según este principio “una clase debería tener una, y solo una, razón para cambiar”. Es esto, precisamente, “razón para cambiar”, lo que Robert C. Martin identifica como “responsabilidad”.
El principio de Responsabilidad Única es el más importante y fundamental de SOLID, muy sencillo de explicar, pero el más difícil de seguir en la práctica.
El propio Bob resume cómo hacerlo: “Gather together the things that change for the same reasons. Separate those things that change for different reasons”, es decir: “Reúne las cosas que cambian por las mismas razones. Separa aquellas que cambian por razones diferentes”.
2. Principio de Abierto/Cerrado
“You should be able to extend a classes behavior, without modifying it.”
“Debería poder extender el comportamiento de una clase, sin modificarlo”.
El segundo principio de SOLID lo formuló Bertrand Meyer en 1988 en su libro “Object Oriented Software Construction” y dice: “Deberías ser capaz de extender el comportamiento de una clase, sin modificarla”. En otras palabras: las clases que usas deberían estar abiertas para poder extenderse y cerradas para modificarse.
En su blog Robert C. Martin defendió este principio que a priori puede parecer una paradoja.
Es importante tener en cuenta el Open/Closed Principle (OCP) a la hora de desarrollar clases, librerías o frameworks.
3. Principio de Sustitución de Liskov
“Derived classes must be substitutable for their base classes.”
“Las clases derivadas deben ser sustituibles por sus clases base”.
La L de SOLID alude al apellido de quien lo creó, Barbara Liskov, y dice que “las clases derivadas deben poder sustituirse por sus clases base”.
Esto significa que los objetos deben poder ser reemplazados por instancias de sus subtipos sin alterar el correcto funcionamiento del sistema o lo que es lo mismo: si en un programa utilizamos cierta clase, deberíamos poder usar cualquiera de sus subclases sin interferir en la funcionalidad del programa.
Según Robert C. Martin incumplir el Liskov Substitution Principle (LSP) implica violar también el principio de Abierto/Cerrado.
4. Principio de Segregación de la Interfaz
“Make fine grained interfaces that are client specific.”
“Haga interfaces de grano fino que sean específicas del cliente”.
En el cuarto principio de SOLID, el tío Bob sugiere: “Haz interfaces que sean específicas para un tipo de cliente”, es decir, para una finalidad concreta.
En este sentido, según el Interface Segregation Principle (ISP), es preferible contar con muchas interfaces que definan pocos métodos que tener una interface forzada a implementar muchos métodos a los que no dará uso.
5. Principio de Inversión de Dependencias
“Depend on abstractions, not on concretions.”
“Depende de abstracciones, no de concreciones”.
Llegamos al último principio: “Depende de abstracciones, no de clases concretas”.
Así, Robert C. Martin recomienda:
- Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de abstracciones.
- Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones.
El objetivo del Dependency Inversion Principle (DIP) consiste en reducir las dependencias entre los módulos del código, es decir, alcanzar un bajo acoplamiento de las clases.
Conclusión
Los principios SOLID son eso: principios, es decir, buenas prácticas que pueden ayudar a escribir un mejor código: más limpio, mantenible y escalable. Que al final de cuenta es lo que buscamos dentro de nuestro proyecto de software.
Como habla Robert C. Martin en su artículo “Getting a SOLID start” no se trata de reglas, ni leyes, ni verdades absolutas, sino más bien soluciones de sentido común a problemas comunes.
Si les gusto este articulo, no olvides compartirlo, comentar tus dudas y dejarnos nuevos temas de interés en los comentarios.
