Principios SOLID
SOLID(Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion). Establece unos consejos que son usados como base para desarrollar y que generan en lo que ello respecta un código más duradero y robusto, en lo que desarrollo de software respecta en base a patrones y arquitectura que conforma un buen código. En definitiva, desarrollar un software de calidad.
Los 5 principios SOLID de diseño de aplicaciones de software son:
- S – Single Responsibility Principle (SRP)
- O – Open/Closed Principle (OCP)
- L – Liskov Substitution Principle (LSP)
- I – Interface Segregation Principle (ISP)
- D – Dependency Inversion Principle (DIP)
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.
¿Qué son la cohesión y el acoplamiento?
Son dos conceptos muy relevantes a la hora de diseñar y desarrollar software. Veamos en qué consisten.
Acoplamiento
El acoplamiento se refiere al grado de interdependencia que tienen dos unidades de software entre sí, entendiendo por unidades de software: clases, subtipos, métodos, módulos, funciones, bibliotecas, etc.
Si dos unidades de software son completamente independientes la una de la otra, decimos que están desacopladas.
Cohesión
La cohesión de software es el grado en que elementos diferentes de un sistema permanecen unidos para alcanzar un mejor resultado que si trabajaran por separado. Se refiere a la forma en que podemos agrupar diversas unidades de software para crear una unidad mayor.
1. Principio de Responsabilidad Única(Single Responsibility Principle (SRP))
Según este principio una clase tendría que tener una y solo una razón para cambiar. A lo que Robert C.Martin identifica como responsabilidad.
2. Principio de Abierto/Cerrado(Open/Closed Principle (OCP))
Debería ser capaz de extender el comportamiento de la clase sin modificarla. Las clases deben ser abiertas para extenderse y cerradas para modificarse.
3. Principio de Sustitución de Liskov(Liskov Substitution Principle (LSP))
Las clases derivadas deben poder sustituirse, por sus clases base. Deberíamos poder usar cualquiera de sus subclases sin interferir en la funcionalidad del programa.
4. Principio de Segregación de la Interfaz(Interface Segregation Principle (ISP))
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 (Dependency Inversion Principle (DIP))
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.
No comment yet, add your voice below!