PRINCIPIO SOLID

La POO (programación orientada a objetos) nos permite agrupar entidades con funcionalidades parecidas entre si, pero esto no implica que los programas no se vuelvan confusos o difíciles de mantener.

Estos principios se llamaron S.O.L.I.D. por sus siglas en inglés:

·         S: Single responsability principle

·         O: Open/Closed principle

·         L: Liskov Substitution principles

·         I: Interface Segregation principle

·         D: Dependency inversion principle

S: Principio de responsabilidad única

Una clase, componente o microservicio debe ser responsable de una sola cosa (desacoplamiento).

O: Principio abierto/cerrado

Establece que las entidades software (clases, modulo y funciones) deberían estar abiertos para su extensión, pero cerrados para su modificación.

L: Principio de sustitución LisKov

Una subclase debe ser sustituible por su superclase, y si al hacer esto, el programa falla, estaremos violando este principio.

I: Principio de segregación de interfaz

Establece que los clientes no deberían verse forzados a depender de interfaces que no usan.

D: Principio de inversión de dependencias

Establece que las dependencias deben estar en las abstracciones, no en las concreciones.

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

·         Las abstracciones no deberían depender de detalles. Los detalles deberían depender de abstracciones.

En algún momento nuestro programa o aplicación llegará a estar formado por muchos módulos. Cuando esto pase, es cuando debemos usar inyección de dependencias, lo que nos permitirá controlar las funcionalidades desde un sitio concreto en vez de tenerlas esparcidas por todo el programa. Además, este aislamiento nos permitirá realizar testing mucho más fácilmente.

Supongamos que tenemos una clase para realizar el acceso a datos, y lo hacemos a través de una BBDD: