Dependency inversion principle / Principio de inversión de dependencias
0. Índice de contenidos.
- 1. Introducción
- 2. Dependency inversion principle / Principio de inversión de dependencias
- 3. Ejemplo
- 4. Conclusiones
- 5. Principio S.O.L.I.D.
1. Introducción
Comenzamos con el último de los principios S.O.L.I.D., el de inversión de dependencias.
Fue postulado inicialmente por Robert C. Martin (Uncle Bob) a mediados de los noventa en un artículo de diseño orientado a objetos en C++.
Es la base teórica sobre la que se basa la inyección de dependencias usada por muchos frameworks, como Spring, por lo que es fácil que os suene.
Fue un concepto bastante innovador, porque supuso romper con el diseño conocido hasta esa fecha, darle la vuelta a las dependencias entre objetos para reducir su acoplamiento y que puedan reutilizarse y cambiarse más fácilmente.
2. Dependency inversion principle / Principio de inversión de dependencias
Estas premisas definen el principio.
A: Los módulos de alto nivel no deberían depender de los de bajo nivel. Ambos deberían depender de abstracciones.
B: Las abstracciones no deberían depender de los detalles. Son los detalles los que deberían depender de abstracciones.
En la orientación a objetos, lo normal es tener una jerarquía de objetos que se unen porque los de más alto nivel suelen incluir una instancia de los de más bajo nivel.
Un bosque contiene árboles, que a su vez contienen hojas, que contienen células…
Por eso se eligió la palabra “inversión”, porque rompe con esta dinámica.
Lo que se pretende es que no exista la necesidad de que los módulos dependan unos de otros, sino que dependan de abstracciones. De esta forma, nuestros módulos pueden ser más fácilmente reutilizables.
3. Ejemplo
En esta ocasión voy a utilizar el ejemplo original del artículo de Robert C. Martin en el que se expuso este principio.
Consideremos un objeto botón y un objeto lámpara. El objeto botón reacciona a un estímulo cambiando su estado entre encendido y apagado. Puede ser un botón físico, uno de una interfaz gráfica en nuestro teléfono, o incluso algún tipo de sensor.
La lámpara si recibe la orden de encenderse o de apagarse actuará en consecuencia, no importa qué tipo de lámpara sea.
Una modelización clásica de este sistema sería una clase botón que contiene una instancia de la clase lámpara, a la que cambia su estado entre encendida y apagada.
El problema de este modelo es que el botón está demasiado acoplado a la lámpara innecesariamente, a este botón le costaría encender y apagar un motor por ejemplo, porque ya tiene la lampara dentro de su estructura.
Vamos a aplicar la inversión de dependencias a este sistema a ver qué conseguimos.
Ahora ya no se conocen entre sí el botón y la lámpara pero pueden funcionar juntos. De hecho, podríamos cambiar fácilmente el objeto que interactúa con el botón para que fuera un motor de un coche por ejemplo.
La interfaz botón no tiene ni que conocer como funciona el mecanismo del botón concreto ni saber nada sobre la lámpara.
Algunos estaréis pensando que seguramente nuestro botón esté pensado para utilizarse sólo en lámparas, por genéricas que estas sean.
Pero esto se puede solucionar con la ayuda de un patrón adaptador que adapte la información que recibe el objeto con la que espera recibir. Es una manera fácil de trabajar con software de terceros que no podemos cambiar por ejemplo.
4. Conclusiones
El forzarme a explicar estos cinco principios de diseño me ha servido para terminar de comprender pequeños detalles en los que nunca me habia fijado mucho. Por lo que estoy contento de haberlos compartido con vosotros y os agradezco vuestras muestras de apoyo.
Espero que os hayan gustado. Estos principios están en un nivel más alto que los patrones de diseño. No son un ejemplo concreto que debáis utilizar para resolver un problema. Son una forma de pensar, ideas que hay que tener en la cabeza mientras se programa para intentar mantener un código limpio y mantenible.
Como dice Robert C. Martin en Clean Code, lo más probable es que el siguiente que va a tener que mantener el código que tú has creado, vas a ser tú mismo. Aunque sólo sea por esto, debemos mantener un código de calidad para poder decir con orgullo, que somos informáticos y programadores.
excelente la claridad de los post! entendi && re-entendi varias cosas que me habian quedado perdidas. Saludos y gracias por la buena onda!
Excelente artículo Samuel. Llevo un par de meses en un bootcamp De Full Stack Java Developer que ha sido mi primer acercamiento a este nuevo y cada vez más fascinante mundo y como comprenderás, debido a la naturaleza propia de un bootcamp se omiten varios detalles teóricos o bien no se profundiza lo suficiente en ellos privilegiando la práctica. Este artículo me ayudó a comprender el porqué de varios procesos e implementaciones que en primera instancia podían parecer exageradas por fragmentar tanto el código en diferentes clases y métodos. Gracias nuevamente por tu trabajo. Saludos desde Chile.