PRINCIPOS SOLID - ESQUEMATIZADO - SIN EJEMPLOS

S.O.L.I.D.

1.- SOLID es el acronimo qeu acuño Michael Feathers, basándose en los 5 principios de al programación orientada a objetos que Robert C. Martin había recopilado en el año 2000 en su paper "Design Principles and Dsign Patterns".

2.- Los objetivos de estos 5 principios a la hora de escribir código son:

a.- Crear un software eficaz: que cumpla con su cometido y que sea robusto y estable.

b.- Escribir un código limpio y flexible ante los cambios: que se pueda modificar fácilmente según necesidad, que sea reutilizable y mantenible.

c.- Permitir escalabilidad: que acepte ser ampliado con nuevas funcionalidades de manera ágil.

3.- La aplicación de los principios SOLID está muy relacionada con la comprensión y el uso de patrones de diseño, que permitirán minimizar el acoplamiento (grado de interdependencia que tienen dos unidades de software entre sí) y maximizar la cohesión (grado en que elementos diferentes de un sistema permanecen unidos para alcanzar un mejor resultado que si trabajaran por separado).

S.O.L.I.D.

S

Single Responsability Principle (SRP)

Principio de responsabilidad única

O

Open/Closed Principle (OCP)

Principio de abierto-cerrado

L

Liskov Substitution Principle (LSP)

Principio de sustitución de Liskov

I

Interface Segretation Principle (ISP)

Principios de segregación de interfaces

D

Dependency Inversion Principle (DIP)

Principio de inversión de dependencias

1.- Principio de Responsabilidad Única

a.- La S del acrónimo del que hablamos hoy se refiere a Single Responsability 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".

b.- 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.

c.- El propio Bob resume cómo hacerlo: "Reúne las cosas que ambian por las mismas razones. Separa aquellas que cambian por razones diferentes".

2.- Principio de Abierto/Cerrado

a.- 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.

b.- En su blog Robert C. Martin defendió este principio que a priori puede parecer una paradoja.

c.- Es importante tener en cuenta el Open/Closed Principle (OCP) a la hora de desarrollar clases, librerías, frameworks, microservicios.

3.- Principio de Sustitución de Liskov

a.- 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".

b.- Esto significa que los objetos deben poder ser reemplazados por instancias 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.

c.- Según Robert. C. Martin incumplir el Liskov Principle Subsitution Principle (LSP) implica violar también el principio de Abierto/Cerrado.

4.- Principio de Segregación de la Interfaz

a.- 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.

b.- 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

a.- Legamos al último principio: "Depende de abstracciones, no de clases concretas".

b.- Así, Robert C. Martin recomienda:

1.- Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de abstracciones.

2.- Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones.

3.- 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.