Principio de Spring IOC, esta puede ser la explicación más fácil de entender

1. Antecedentes de la teoría de la COI

Todos sabemos que en un sistema de software diseñado con métodos orientados a objetos, su implementación subyacente se compone de N objetos, y todos los objetos cooperan entre sí para finalmente realizar la lógica comercial del sistema.

Figura 1: Objetos acoplados en un sistema de software

Si abrimos la tapa trasera de un reloj mecánico, vemos una situación similar a la anterior, con los respectivos engranajes moviendo las manecillas de horas, minutos y segundos en el sentido de las agujas del reloj para generar la hora correcta en el dial. Uno de estos conjuntos de engranajes se muestra en la Figura 1, que tiene múltiples engranajes independientes que se engranan entre sí y trabajan juntos para realizar una tarea. Podemos ver que en un conjunto de engranajes de este tipo, si hay un problema con un engranaje, puede afectar el funcionamiento normal de todo el conjunto de engranajes.

La relación de engrane entre engranajes en un conjunto de engranajes es muy similar a la relación de acoplamiento entre objetos en un sistema de software. La relación de acoplamiento entre objetos es ineludible y necesaria, que es la base del trabajo colaborativo. Ahora, con la escala cada vez mayor de las aplicaciones industriales, las dependencias entre objetos son cada vez más complejas y, a menudo, aparecen múltiples dependencias entre objetos, por lo que los arquitectos y diseñadores necesitan analizar y analizar el diseño, se enfrentarán a mayores desafíos. Un sistema con demasiado alto acoplamiento entre los objetos conducirá inevitablemente a una situación que afecta a todo el cuerpo.

Figura 2: Dependencias complejas entre objetos

Las relaciones de acoplamiento no solo aparecen entre objetos, sino también entre módulos de sistemas de software y entre sistemas de software y sistemas de hardware. Cómo reducir el acoplamiento entre sistemas, módulos y objetos es uno de los objetivos que siempre persigue la ingeniería de software. Para resolver el problema del acoplamiento excesivo entre objetos , el experto en software Michael Mattson propuso la teoría IOC para realizar el "desacoplamiento" entre objetos. En la actualidad, esta teoría se ha aplicado con éxito en la práctica, y muchos proyectos J2EE utilizan el marco IOC. producto Primavera.

2. ¿Qué es la inversión de control (IOC)?

IOC es la abreviatura de Inversion of Control. La mayoría de los libros se traducen como "Inversion of Control", y algunos libros se traducen como "Inversion of Control" o "Inversion of Control".

En 1996, Michael Mattson propuso por primera vez el concepto de IOC en un artículo sobre la exploración de marcos orientados a objetos. Ya hemos hablado mucho sobre las ideas básicas del diseño y la programación orientada a objetos, por lo que no las repetiré. En resumen, se trata de descomponer un sistema complejo en objetos que cooperan entre sí. Después de que estas clases de objetos se encapsulan , la implementación interna es transparente hacia el exterior, lo que reduce la complejidad de resolver el problema y puede reutilizarse y extenderse de manera flexible. El punto de vista propuesto por la teoría IOC es más o menos el siguiente: el desacoplamiento entre objetos con dependencias se realiza por medio de un "tercero", como se muestra en la siguiente figura:

Figura 3: proceso de desacoplamiento de IOC

Como puede ver, debido a la introducción del "tercero" en la posición media, es decir, el contenedor IOC, los cuatro objetos A, B, C y D no tienen relación de acoplamiento, y la transmisión entre los engranajes todos Confíe en el "tercero". El control de todos los objetos se entrega al contenedor IOC de "terceros". Por lo tanto, el contenedor IOC se ha convertido en el núcleo clave de todo el sistema. Actúa como un "pegamento" para pegar. todos los objetos en el sistema Para funcionar juntos, sin este "pegamento", los objetos perderán contacto entre sí, razón por la cual algunas personas comparan el contenedor IOC con el "pegamento".

Hagamos otro experimento: retire el contenedor IOC en el medio de la imagen de arriba y luego observe el sistema:

Figura 4: El sistema con el contenedor IoC retirado

La imagen que vemos ahora es todo lo que necesitamos hacer para implementar todo el sistema. En este momento, no hay relación de acoplamiento entre los cuatro objetos A, B, C y D, y no hay conexión entre ellos. En este caso, cuando implementa A, no necesita considerar B, C , y D. Las dependencias entre objetos se han reducido al mínimo. Por lo tanto, si el contenedor IOC realmente se puede implementar, será algo maravilloso para el desarrollo del sistema. Cada miembro que participa en el desarrollo solo necesita implementar su propia clase, ¡y no tiene nada que ver con los demás!

Echemos un vistazo de nuevo ¿Por qué se llama así Inversión de Control (IOC)? Comparemos:

• Antes de que el sistema de software introduzca el contenedor IOC, como se muestra en la Figura 1, el objeto A depende del objeto B, por lo que cuando el objeto A se inicializa o se ejecuta hasta cierto punto, debe crear activamente el objeto B o usar el objeto B ya creado. Ya sea que se cree o se use el objeto B, el control está en sus propias manos.
• Después de la introducción del contenedor IOC en el sistema de software, esta situación ha cambiado por completo. Como se muestra en la Figura 3, debido a la adición del contenedor IOC, se pierde la conexión directa entre el objeto A y el objeto B. Por lo tanto, cuando el objeto A corre hasta el punto donde se requiere el objeto B En ese momento, el contenedor IOC creará activamente un objeto B y lo inyectará en el lugar donde el objeto A lo necesita.

A través de la comparación antes y después, no es difícil ver que el proceso del objeto A para obtener el objeto dependiente B ha cambiado de un comportamiento activo a un comportamiento pasivo, y los derechos de control se han invertido. Este es el origen del nombre "inversión de control".

3. Alias ​​de IOC: Inyección de Dependencia (DI)

En 2004, Martin Fowler discutió la misma pregunta. Dado que IOC es una inversión de control, ¿qué es exactamente "en qué aspectos del control se han invertido? Después de un análisis y argumentación detallados, llegó a la respuesta: "Obtenga el El proceso de depender de los objetos es al revés". Una vez invertido el control, el proceso de obtención de objetos dependientes cambia de autogestión a inyección activa por parte del contenedor IOC. Entonces, le dio a "Inversión de control" un nombre más apropiado llamado "Inyección de dependencia (Dependency Injection)". Su respuesta, de hecho, da la forma de lograr IOC: inyección. La llamada inyección de dependencia es que el contenedor IOC inyecta dinámicamente una cierta dependencia en el objeto durante la operación.

Por lo tanto, la inyección de dependencia (DI) y la inversión de control (IOC) describen lo mismo desde diferentes perspectivas, es decir, al introducir un contenedor IOC y usar la inyección de dependencia para lograr el desacoplamiento entre objetos .

Tomemos un ejemplo de la vida real para ayudar a comprender el proceso de inyección de dependencia. Todo el mundo debería estar familiarizado con las interfaces USB y los dispositivos USB. El USB nos proporciona una gran comodidad en el uso de ordenadores. Ahora, muchos dispositivos externos admiten interfaces USB.

Figura 5: interfaz USB y dispositivo USB

Ahora, usamos el host de la computadora y la interfaz USB para lograr una tarea: leer un archivo desde un dispositivo USB externo.

Cuando la computadora host lee el archivo, no le importa en absoluto qué dispositivo externo está conectado a la interfaz USB, y realmente no necesita saberlo. Su tarea es leer la interfaz USB, siempre que el dispositivo externo conectado cumpla con el estándar de interfaz USB. Por lo tanto, si conecto un disco U a la computadora host, la computadora host leerá los archivos del disco U; si conecto un disco duro externo a la computadora host, la computadora host leerá los archivos del disco duro externo. El poder de conectar dispositivos externos depende de mí, es decir, el derecho de control me pertenece. En cuanto a qué dispositivo está conectado a la interfaz USB, la computadora host no puede decidir, solo puede aceptarlo pasivamente. Cuando la computadora central necesita un dispositivo externo, no necesito que me lo diga, y tomaré la iniciativa para ayudarlo a conectar el dispositivo externo que desee. Puede ver lo bueno que es mi servicio. Este es un ejemplo común de inyección de dependencia en nuestra vida. En este proceso, desempeñé el papel del contenedor IOC .

A través de este ejemplo, la idea de la inyección de dependencia es muy clara: cuando el host de la computadora lea el archivo, lo ayudaré a conectar el dispositivo externo del que depende. Todo el proceso de inyección de dispositivos externos es exactamente el mismo que el proceso de inyección de un objeto dependiente en otro objeto cuando el sistema se está ejecutando.

Aplicamos la inyección de dependencia al sistema de software y luego describimos el proceso:

El objeto A depende del objeto B. Cuando el objeto A necesita usar el objeto B, el contenedor IOC creará inmediatamente un objeto B y lo enviará al objeto A. El contenedor IOC es una fábrica de fabricación de objetos. Lo que necesita, se le enviará, puede usarlo directamente y ya no necesita preocuparse por cómo se fabrican las cosas que usa o cómo se destruyen al final. , todos los cuales son manejados por el contenedor IOC.

En las implementaciones tradicionales, la relación entre los componentes está controlada por código dentro del programa. A menudo usamos la palabra clave new para darnos cuenta de la combinación de la relación entre dos componentes, lo que provocará el acoplamiento entre los componentes. IOC resuelve muy bien este problema, se dará cuenta de la relación entre los componentes desde el interior del programa al contenedor externo, es decir, el contenedor inyectará dinámicamente algún tipo de dependencia entre los componentes en el componente durante el tiempo de ejecución.

4. ¿Qué beneficios nos aporta IOC?

Comencemos con el ejemplo de USB ¿Cuáles son los beneficios de usar un dispositivo externo USB en lugar de un disco duro interno?

1. Como dispositivo externo del host de la computadora, el dispositivo USB no tiene nada que ver con el host de la computadora antes de que se inserte en la computadora host. Solo después de conectarlo, los dos están conectados y relacionados. Por lo tanto, no importa lo que le suceda a cualquiera de los lados, no afectará la operación del otro lado. Esta característica se refleja en la ingeniería de software, es decir, la capacidad de mantenimiento es relativamente buena, es muy conveniente para las pruebas unitarias y es conveniente para depurar programas y diagnosticar fallas. Cada clase en el código se puede probar por separado sin afectarse entre sí, siempre que se garantice que su propia función es correcta, este es el beneficio del acoplamiento bajo o sin acoplamiento entre los componentes.
2. La irrelevancia entre el dispositivo USB y el host de la computadora también trae otro beneficio. El fabricante del dispositivo USB y el fabricante del host de la computadora pueden no tener ninguna relación entre sí. Es el estándar de interfaz USB. Esta característica se refleja en el proceso de desarrollo de software y los beneficios son demasiado grandes. Cada miembro del equipo de desarrollo solo debe preocuparse por implementar su propia lógica comercial y no necesita preocuparse por el progreso del trabajo de otras personas, porque sus tareas no tienen nada que ver con otras, sus tareas se pueden probar individualmente y su las tareas no necesitan depender de los componentes de otras personas, ya no hay que hablar de la responsabilidad. Por lo tanto, en un proyecto grande y mediano, los miembros del equipo tienen una división clara del trabajo y las responsabilidades. Es fácil dividir una tarea grande en tareas pequeñas, y la eficiencia del desarrollo y la calidad del producto mejorarán considerablemente.
3. El mismo dispositivo externo USB se puede conectar a cualquier dispositivo compatible con USB, se puede conectar a un host de computadora o se puede conectar a una máquina DV, y el dispositivo externo USB se puede usar repetidamente. En ingeniería de software, esta característica es una buena reutilización. Podemos aislar componentes comunes comunes y reutilizarlos en otras partes del proyecto u otros proyectos. Por supuesto, esta también es la característica básica de la orientación a objetos. Obviamente, IOC no solo implementa mejor este principio, sino que también mejora la reutilización de los módulos. Las implementaciones que se ajustan al estándar de interfaz se pueden conectar a módulos compatibles con este estándar.
4. Al igual que los periféricos USB, los módulos son intercambiables en caliente. Se cambia el método de generación de objetos de IOC a un método externo, es decir, la generación de objetos se define en el archivo de configuración, de esta forma cuando reemplacemos una subclase de implementación, se volverá muy simple, solo modifique el archivo de configuración. característica de intercambio.

¿Los beneficios anteriores no son suficientes para impresionarnos y permitirnos usar el marco IOC en el proceso de desarrollo del proyecto?

5. Análisis técnico de contenedores IOC

La tecnología más básica en IOC es la programación "Reflection". Actualmente, se admiten lenguajes como .Net C#, Java y PHP5. Entre ellos, los libros técnicos de PHP5 a veces se traducen a "mapeo". Todo el mundo debe tener muy claro el concepto y el uso de la reflexión.En términos generales, se trata de generar objetos dinámicamente de acuerdo con el nombre de clase dado (método de cadena) . Esta forma de programación permite que el objeto decida qué tipo de objeto es cuando se crea. La aplicación de la reflexión es muy extensa. Muchos marcos maduros, como Hibernate y Spring framework en Java, NHibernate y Spring.Net framework en .Net, todos usan "reflexión" como el medio técnico más básico.

La tecnología de reflexión apareció muy pronto, pero se ha ignorado y no se ha vuelto a utilizar. La programación reflexiva en ese momento era al menos 10 veces más lenta que la generación normal de objetos. La tecnología de reflexión actual se ha mejorado y optimizado, y se ha vuelto muy madura.El método de reflexión genera objetos y el método de generación de objetos normal, la velocidad no es muy diferente, aproximadamente 1-2 veces la brecha.

Podemos considerar el modo de trabajo del contenedor IOC como la sublimación del modo de fábrica.Podemos considerar el contenedor IOC como una fábrica.Los objetos que se producirán en esta fábrica se definen en el archivo de configuración y luego usan la programación de reflexión de el lenguaje de programación. , genere el objeto correspondiente de acuerdo con el nombre de clase dado en el archivo de configuración. Desde el punto de vista de la implementación, IOC es cambiar el código de generación de objetos que se escribió previamente en el método de fábrica para que sea definido por el archivo de configuración, es decir, separar la fábrica y la generación de objetos de forma independiente. El propósito es mejorar la flexibilidad y mantenibilidad

6. Algunos productos del contenedor IOC

Los contenedores IOC bajo el sistema de tecnología Sun ONE incluyen: Spring, Guice, Pico Container, Avalon, HiveMind para livianos; EJB para pesados; JBoss, Jdon, etc. Como uno de los tres mosqueteros de SSH (Struts, Spring, Hibernate) en el desarrollo de Java, Spring framework se usa en proyectos grandes, medianos y pequeños. Es muy maduro y se usa ampliamente. EJB también se usa en proyectos industriales clave, como algún negocio de telecomunicaciones.

Los contenedores IOC bajo el sistema de tecnología .Net incluyen: Spring.Net, Castle, etc. Spring.Net es un contenedor IOC trasplantado de Spring de Java, y el contenedor IOC de Castle es la parte de Windsor. Todos son marcos ligeros y relativamente maduros, entre los cuales Spring.Net se ha aplicado gradualmente a varios proyectos.

7. A qué se debe prestar atención cuando se utiliza el marco IOC

El uso de los productos del marco IOC puede traer grandes beneficios a nuestro proceso de desarrollo, pero debemos comprender completamente las deficiencias de la introducción de los marcos IOC, ser conscientes de ellas y evitar el abuso del marco.

1. Debido a la introducción de un contenedor IOC de terceros en el sistema de software, los pasos para generar objetos se han vuelto un poco complicados. Originalmente era un asunto entre los dos, y se agregó un procedimiento adicional de la nada. Por lo tanto, cuando empezamos a usar el marco IOC, sentiríamos que el sistema se vuelve menos intuitivo. Por lo tanto, la introducción de un nuevo marco aumentará el costo de capacitación para que los miembros del equipo aprendan y comprendan, y en la futura operación y mantenimiento, los nuevos participantes deben tener el mismo sistema de conocimiento.
2. Dado que el contenedor IOC genera objetos a través de la reflexión, existe una cierta pérdida de eficiencia operativa. Esto debe sopesarse si lo que busca es eficiencia operativa.
3. Específicamente, para los productos del marco IOC (como Spring), se requiere mucho trabajo de preparación, lo cual es relativamente engorroso.Para algunos proyectos pequeños, puede aumentar objetivamente algunos costos de trabajo.
4. Es necesario evaluar la madurez del producto marco IOC en sí mismo. Si se introduce un producto marco IOC inmaduro, afectará a todo el proyecto, por lo que también es un riesgo oculto.

En general podemos sacar las siguientes conclusiones:

Algunos proyectos o productos con poca carga de trabajo no son adecuados para utilizar los productos del marco IOC. Además, si los miembros del equipo carecen de conocimientos y habilidades, y carecen de una comprensión profunda de los productos del marco IOC, no los presente precipitadamente.

Finalmente, los proyectos o productos que enfatizan la eficiencia operativa no son muy adecuados para la introducción de productos marco IOC, como es el caso de los sitios web WEB2.0.