Introducción
Con el auge de la programación orientada a objetos (POO) el código de las aplicaciones paso de ser lineal y predecible a tener un flujo más complejo, con múltiples saltos entre módulos y componentes, pero atrajo dos grandes ventajas: la modularidad y la reutilización de estos componentes. El problema es que la modularidad venía con un problema bajo el brazo que se fue haciendo cada vez más grande: la dependencia entre módulos.
Hemos hablado en otras ocasiones sobre las dependencias entre módulos y componentes, así que no voy a entrar mucho más en detalle en este problema.
Cuando el problema de la dependencia se hizo demasiado grande aparecieron dos nuevos conceptos de diseño:
La Inversión de Control (IoC)
La inyección de dependencias (DI)
Con la aparición de frameworks de desarrollo, la inversión de control se convirtió en una forma de desarrollo bastante habitual, ya que es el framework el que toma el control, el que define el flujo de actuación o el ciclo de vida de una petición, el framework es quien ejecuta el código de usuario
La inversión de control se da cuando son las librerías o framework quienes ejecutan el código de usuario
El nombre de “Principio de Hollywood” viene de la habitual frase empleada por los directores de casting en Hollywood para evitar estar recibiendo llamadas de aspirantes preguntado si han sido aceptados o no.
Usos de IoC
La inversión de control tiene numerosos casos de uso, siendo los frameworks de desarrollo el ejemplo más claro.
Otros usos destacados de IoC es el que se hace en algunos conocidos patrones de diseño:
La inversión de control juega un papel bastante importante en la extensibilidad del código, ya que entre otras cosas, nos permite ampliar la funcionalidad de nuestro sistema sin tener que modificar las clases existentes
Un ejemplo práctico
La mayoría de frameworks PHP proveen al usuario de un sistema de eventos custom: Symfony, Laravel, Yii…
Los sistemas de eventos se basan en el principio de IoC, ya que durante la subscripción a determinado evento suelen recibir dos parámetros: el evento al que se subscriben y un callable que ejecutar. Veamos un ejemplo con el EventDispatcher de Symfony:
Si quisiéramos ampliar la funcionalidad de la aplicación haciendo algo más después de un registro de usuario sería tan sencillo como crear un nuevo listener y subscribirlo al evento. Y no solo esto, podemos crear tantos eventos custom como queramos y subscribir tantos listeners como se necesite.
Conclusión
La IoC está presente en nuestro día a día aunque no seamos conscientes de ello, y esto ha contribuido a que nuestro software sea más escalable, modular, reutilizable y fácil de mantener.
Lleva presente mucho tiempo en conocidos frameworks de desarrollo de aplicaciones de escritorio como .NET, Java Spring está desarrollado basándose en este concepto, y los nuevos frameworks web como Symfony, Rails… también han se han basado en él.
Espero que este post haya servido para comprender el concepto de IoC, ya que en breve comenzaré una serie de artículos sobre patrones de diseño, su aplicación y como refactorizar nuestro código para implementarlos, y este me ha parecido un buen tema para abrir boca sobre el tema; así como afianzar un poco lo aprendido en el último post sobre Inversión de Dependencias e Inyección de Dependencias.
Hasta la próxima!
Top comments (0)