¿Qué es la Inversión de Control?

La inversión de control es lo que obtienes cuando tu programa devuelve las llamadas, por ejemplo, como un programa gui.

Por ejemplo, en un menú de la vieja escuela, usted podría tener:

print "enter your name"
read name
print "enter your address"
read address
etc...
store in database

Controlando así el flujo de interacción del usuario.

En un programa GUI o algo así, en su lugar decimos:

when the user types in field a, store it in NAME
when the user types in field b, store it in ADDRESS
when the user clicks the save button, call StoreInDatabase

Así que ahora el control está invertido... en lugar de que la computadora acepte la entrada del usuario en un orden fijo, el usuario controla el orden en el que se ingresan los datos y cuándo se guardan base.

Básicamente, cualquier cosa con un bucle de eventos, devoluciones de llamada o disparadores de ejecución cae en esta categoría.

¿Qué es la Inversión de Control?

Si sigues estos dos sencillos pasos, has hecho inversión de control:

1. Separe lo que-hacer parte de cuando-hacer parte.
2. Asegúrese de que cuando parte sabe como poco como sea posible acerca de lo que parte; y viceversa.

Hay varias técnicas posibles para cada uno de estos pasos basados en la tecnología / lenguaje que está utilizando para su aplicación.

--

La inversión parte de la Inversión de Control (IoC) es lo confuso; porque inversión es el término relativo. ¡La mejor manera de entender el CoI es olvidarse de esa palabra!

--

Ejemplos

• Gestión de eventos. Controladores de eventos (parte de qué hacer) Raising Elevar eventos (parte de cuándo hacer)
• Interfaces. Component client (when-to-do part) implementation Implementación de interfaz de componente (qué hacer part)
• xUnit fixure. Setup and TearDown (what-to-do part) {xUnit frameworks llama a Setup al principio y TearDown al final (when-to-do part)
• Patrón de diseño del método de plantilla. template method when-to-do part implementation primitive subclass implementation what-to-do part
• Métodos contenedor DLL en COM. DllMain, DllCanUnload, etc (qué-a-hacer parte) COM COM/OS (cuándo-a-hacer parte)

La inversión de los controles consiste en separar las preocupaciones.

Sin IoC : Tienes un ordenador laptop y accidentalmente rompes la pantalla. Y maldita sea, usted encuentra el mismo modelo de pantalla de la computadora portátil no está en ninguna parte en el mercado. Así que estás atascado.

Con IoC : Tienes un ordenador desktop y rompes accidentalmente la pantalla. Usted encuentra que usted puede tomar casi cualquier monitor de escritorio del mercado, y funciona bien con su escritorio.

Su desktop implementa con éxito IoC en este caso. Acepta una variedad de tipos de monitores, mientras que el portátil no lo hace, necesita una pantalla específica para arreglarse.

Inversión de Control, (o CoI), se trata de conseguir la libertad (Te casas, perdiste la libertad y estás siendo controlado. Te divorciaste, acabas de implementar la Inversión del Control. Eso es lo que llamamos, "desacoplado". Buen sistema informático desalienta alguna relación muy estrecha.) más flexibilidad (La cocina de su oficina solo sirve agua limpia del grifo, esa es su única opción cuando desea beber. Su jefe implementó la Inversión de Control mediante la creación de un nuevo Cafetera. Ahora tienes la flexibilidad de elegir agua del grifo o café.) y menos dependencia (Su pareja tiene un trabajo, usted no tiene un trabajo, depende financieramente de su pareja, por lo que está controlado. Si encuentras un trabajo, has implementado la Inversión del Control. Un buen sistema informático fomenta la dependencia.)

Cuando usas una computadora de escritorio, has esclavizado (o digamos, controlado). Tienes que sentarte ante una pantalla y mirarla. Usar el teclado para escribir y usar el ratón para navegar. Y un software mal escrito puede esclavizarte aún más. Si reemplaza su escritorio con una computadora portátil, entonces control algo invertido. Puedes tomarlo fácilmente y moverte. Así que ahora puedes controlar dónde estás con tu computadora, en lugar de que tu computadora la controle.

Al implementar la Inversión de Control, un consumidor de software/objeto obtiene más controles/opciones sobre el software/objetos, en lugar de ser controlado o tener menos opciones.

Con el por encima de las ideas en mente. Todavía nos perdemos una parte clave del CoI. En el escenario del CoI, el consumidor de software / objeto es un marco sofisticado. Eso significa que el código que creó no es llamado por usted mismo. Ahora vamos a explicar por qué esta manera funciona mejor para una aplicación web.

Supongamos que su código es un grupo de trabajadores. Necesitan construir un auto. Estos trabajadores necesitan un lugar y herramientas (un marco de software) para construir el automóvil. Un marco de software tradicional será como un garaje con muchos herramienta. Por lo tanto, los trabajadores deben hacer un plan ellos mismos y usar las herramientas para construir el automóvil. Construir un automóvil no es un negocio fácil, será muy difícil para los trabajadores planificar y cooperar adecuadamente. Un marco de software moderno será como una fábrica de automóviles moderna con todas las instalaciones y gerentes en su lugar. Los trabajadores no tienen que hacer ningún plan, los gerentes (parte del marco, son las personas más inteligentes y hicieron el plan más sofisticado) ayudarán a coordinar para que el los trabajadores saben cuándo hacer su trabajo (framework llama a su código). Los trabajadores solo necesitan ser lo suficientemente flexibles para usar cualquier herramienta que los gerentes les den (mediante el uso de la Inyección de dependencias).

Aunque los trabajadores dan el control de la gestión del proyecto en el nivel superior a los gerentes (el marco). Pero es bueno que algunos profesionales ayuden. Este es el concepto de CoI realmente vienen de.

Las aplicaciones web modernas con una arquitectura MVC dependen del marco para hacer la URL Enrutamiento y poner Controladores en su lugar para que el marco llame.

La Inyección de Dependencia y la Inversión del Control están relacionadas. La inyección de dependencia está en el nivel micro y la Inversión de Control está en el nivel macro. Tienes que comer cada bocado (implementar DI) para terminar una comida (implementar IoC).

Antes de usar Inversión de Control debe ser muy consciente del hecho de que tiene sus pros y sus contras y debe saber por qué lo usa si lo hace.

Ventajas:

• Su código se desacopla para que pueda intercambiar fácilmente implementaciones de una interfaz con implementaciones alternativas
• Es un fuerte motivador para codificar contra interfaces en lugar de implementaciones
• Es muy fácil escribir pruebas unitarias para su código porque no depende de nada más que los objetos que acepta en su constructor / setters y puede inicializarlos fácilmente con los objetos correctos de forma aislada.

Contras:

• IoC no solo invierte el flujo de control en su programa, sino que también lo nubla considerablemente. Esto significa que ya no puede leer su código y saltar de un lugar a otro porque las conexiones que normalmente estarían en su código ya no están en el código. En su lugar está en archivos de configuración XML o anotaciones y en el código de su contenedor IoC que interpreta estos metadatos.
• Surge una nueva clase de errores en los que obtiene su configuración XML o sus anotaciones incorrectas y puede pasar mucho tiempo averiguando por qué su contenedor IoC inyecta una referencia nula en uno de sus objetos bajo ciertas condiciones.

Personalmente veo los puntos fuertes del CoI y realmente me gustan, pero tiendo a evitar el CoI siempre que sea posible porque convierte su software en una colección de clases que ya no constituyen un programa "real", pero solo algo que necesita ser reunido por la configuración XML o metadatos de anotación y se caería (y se cae) a pedazos sin él.

1. Artículo de Wikipedia . Para mí, la inversión de control es convertir su código escrito secuencialmente y convertirlo en una estructura de delegación. En lugar de que su programa controle todo explícitamente, su programa establece una clase o biblioteca con ciertas funciones para ser llamadas cuando suceden ciertas cosas.

2. Resuelve la duplicación de código. Por ejemplo, en los viejos tiempos se escribía manualmente su propio bucle de eventos, sondeando las bibliotecas del sistema para nuevos eventos. Hoy en día, la mayoría de las API modernas simplemente le dice a las bibliotecas del sistema qué eventos le interesan, y le informará cuando sucedan.

3. La inversión de control es una forma práctica de reducir la duplicación de código, y si te encuentras copiando un método completo y solo cambiando una pequeña parte del código, puedes considerar abordarlo con inversión de control. La inversión del control se hace fácil en muchos idiomas a través del concepto de delegados, interfaces o incluso raw punteros de función.

   No es apropiado usarlo en todos los casos, porque el flujo de un programa puede ser más difícil de seguir cuando se escribe de esta manera. Es una forma útil de diseñar métodos al escribir una biblioteca que será reutilizada, pero debe usarse con moderación en el núcleo de su propio programa a menos que realmente resuelva un problema de duplicación de código.

Pero creo que hay que tener mucho cuidado con él. Si va a abusar de este patrón, va a hacer un diseño muy complicado y código aún más complicado.

Como en este ejemplo con TextEditor: si usted tiene solo un corrector ortográfico tal vez no es realmente necesario utilizar IoC ? A menos que necesites escribir pruebas unitarias o algo así ...

De todos modos: sé razonable. El patrón de diseño es buenas prácticas pero no Biblia para ser predicada. No lo pegues en todas partes.

Supongamos que usted es un objeto. Y vas a un restaurante:

Sin IoC : pides "apple", y siempre te sirven apple cuando pides más.

Con IoC : Puedes pedir "fruta". Usted puede obtener diferentes frutas cada vez que se sirve. por ejemplo, manzana, naranja o sandía.

Así que, obviamente, el CoI es preferido cuando te gustan las variedades.

IoC / DI para mí está empujando dependencias a los objetos que llaman. Súper simple.

La respuesta no técnica es ser capaz de cambiar un motor en un coche justo antes de encenderlo. Si todo se conecta bien (la interfaz), eres bueno.

1. La inversión de control es un patrón utilizado para desacoplar componentes y capas en el sistema. El patrón se implementa inyectando dependencias en un componente cuando se construye. Estas dependencias generalmente se proporcionan como interfaces para una mayor disociación y para apoyar la capacidad de prueba. Los contenedores IoC / DI como Castle Windsor, Unity son herramientas (bibliotecas) que se pueden utilizar para proporcionar IoC. Estas herramientas proporcionan características extendidas más allá de la simple dependencia gestión, incluida la vida útil , AOP / Interceptación, política, etc.

2. A. Evita que un componente sea responsable de administrar sus dependencias.
   b. Proporciona la capacidad de intercambiar implementaciones de dependencias en diferentes entornos.
   c. Permite que un componente sea probado a través de la burla de dependencias.
   d. Proporciona un mecanismo para compartir recursos a través de una aplicación.

3. A. Crítico cuando se hace un desarrollo basado en pruebas. Sin el CoI puede ser difícil de probar, porque los componentes bajo prueba están altamente acoplados al resto del sistema.
   b. Crítico al desarrollar sistemas modulares. Un sistema modular es un sistema cuyos componentes pueden ser reemplazados sin necesidad de recompilación.
   c. Crítico si hay muchas preocupaciones transversales que deben abordarse, en particular en una aplicación empresarial.

Escribiré mi simple comprensión de estos dos términos:

For quick understanding just read examples*

Inyección de Dependencia (DI):
La inyección de dependencias generalmente significa pasar un objeto del que depende el método, como un parámetro a un método, en lugar de hacer que el método cree el objeto dependiente.
Lo que significa en la práctica es que el método no depende directamente de una implementación en particular; cualquier implementación que cumpla con los requisitos puede pasarse como un parámetro.

Con esto los objetos cuentan sus dependencias. Y la primavera lo hace disponible.
Esto conduce al desarrollo de aplicaciones poco acopladas.

Quick Example:EMPLOYEE OBJECT WHEN CREATED,
              IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
   (if address is defines as dependency by Employee object)

Contenedor de Inversión de Control(CoI):
Esta es una característica común de los marcos, IOC gestiona objetos java
– desde la instanciación hasta la destrucción a través de su fábrica.
- Los componentes Java que son instanciados por el contenedor IoC se llaman beans, y el contenedor IoC administra el ámbito de bean, los eventos de ciclo de vida y cualquier característica de AOP para la que se ha configurado y codificado.

QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it.

Al implementar la Inversión de Control, un consumidor de software/objeto obtiene más controles/opciones sobre el software/objetos, en lugar de ser controlado o tener menos opciones.

La inversión del control como guía de diseño sirve para los siguientes propósitos:

Hay una disociación de la ejecución de una determinada tarea de aplicación.
Cada módulo puede centrarse en lo que está diseñado para.
Los módulos no hacen suposiciones sobre lo que hacen otros sistemas, sino que dependen de sus contratos.
Reemplazar módulos no tiene ningún efecto secundario en otros módulos
Voy a mantener las cosas abstractas aquí, Puede visitar los siguientes enlaces para una comprensión detallada del tema.
Una buena lectura con ejemplo

Explicación Detallada

Respondiendo solo la primera parte. ¿Qué es eso?

Inversión de Control (IoC) significa crear instancias de dependencias primero y última instancia de una clase (opcionalmente inyectándolas a través del constructor), en lugar de crear una instancia de la clase primero y luego la instancia de clase creando instancias de dependencias. Así, la inversión de control invierte el flujo de control del programa. en Lugar de el destinatario controlar el flujo de control (mientras crea dependencias), el llamante controla el flujo de control del programa.

Por ejemplo, la tarea#1 es crear un objeto. Sin el concepto de IOC, la tarea # 1 se supone que debe ser hecha por el Programador.Pero con el concepto del COI, la tarea#1 se haría por contenedor.

En resumen, el control se invierte del Programador al contenedor. Por lo tanto, se llama como inversión de control.

He encontrado un buen ejemplo aquí.

Estoy de acuerdo con NilObject , pero me gustaría añadir a esto:

Si se encuentra copiando un método completo y solo cambiando una pequeña parte del código, puede considerar abordarlo con inversión de control

Si te encuentras copiando y pegando código, casi siempre estás haciendo algo mal. Codificado como el principio de diseño Una vez y Solo Una vez .

Parece que lo más confuso acerca de "IoC" el acrónimo y el nombre que representa es que es demasiado glamoroso de un nombre - casi un nombre de ruido.

¿Realmente necesitamos un nombre con el que describir la diferencia entre la programación procedimental y la basada en eventos? De acuerdo, si es necesario, pero ¿tenemos que elegir un nuevo nombre "más grande que la vida" que confunde más de lo que resuelve?

Digamos que nos reunimos en algún hotel.

Mucha gente, muchas garrafas de agua, muchas tazas de plástico.

Cuando alguien quiere beber, ella llena la taza, bebe y tira la taza al suelo.

Después de una hora o algo tenemos un piso cubierto de vasos de plástico y agua.

Vamos a invertir el control.

La misma reunión en el mismo lugar, pero en lugar de tazas de plástico tenemos un camarero con una taza de vidrio (Singleton)

Y ella todo el tiempo ofrece a invitados bebiendo.

Cuando alguien quiere beber, ella consigue de camarero vaso, beber y devolverlo de nuevo a camarero.

Dejando de lado la cuestión de la higiene, última forma de control del proceso de bebida es mucho más eficaz y económico.

Y esto es exactamente lo que hace el Resorte (otro contenedor del CoI, por ejemplo: Guice). En lugar de dejar que la aplicación cree lo que necesita usando una nueva palabra clave (tomando una taza de plástico), el contenedor IOC de primavera ofrece todo el tiempo a la aplicación la misma instancia (singleton) del objeto necesario(vaso de agua).

Piensa en ti mismo como organizador de tal reunión. Necesita la forma de enviar un mensaje a la administración del hotel que

Los miembros de la Reunión necesitarán un vaso de agua, pero no pan comido.

Ejemplo:-

public class MeetingMember {

    private GlassOfWater glassOfWater;

    ...

    public void setGlassOfWater(GlassOfWater glassOfWater){
        this.glassOfWater = glassOfWater;
    }
    //your glassOfWater object initialized and ready to use...
    //spring IoC  called setGlassOfWater method itself in order to
    //offer to meetingMember glassOfWater instance

}

Útil enlaces:-

• http://adfjsf.blogspot.in/2008/05/inversion-of-control.html
• http://martinfowler.com/articles/injection.html
• http://www.shawn-barrett.com/blog/post/Tip-of-the-day-e28093-Inversion-Of-Control.aspx

IoC se trata de invertir la relación entre su código y el código de terceros (biblioteca/marco):

• En el desarrollo s/w normal, se escribe la principal() método y métodos de llamada "biblioteca". Tú están en control:)
• En el CoI los controles" framework" principal() y llama a tus métodos. Las Marco está en control: (

DI (Inyección de dependencias) trata sobre cómo el control fluye en el aplicación. La aplicación de escritorio tradicional tenía flujo de control desde su aplicación (método main ()) a otras llamadas a métodos de biblioteca, pero con DI control flow se invierte ese marco se encarga de iniciar su aplicación, inicializarla e invocar sus métodos cuando sea necesario.

Al final siempre ganas:)

He encontrado un ejemplo muy claro aquí que explica cómo se invierte el 'control'.

Código clásico (sin inyección de dependencia)

Así es como funciona un código que no usa DI:

• La aplicación necesita Foo (por ejemplo, un controlador), por lo que:
• La aplicación crea Foo
• La aplicación llama a Foo
  • Foo necesita Bar (por ejemplo, un servicio), así que:
  • Foo crea Bar
  • Foo llama a Bar
    • La barra necesita Bim (un servicio, un repositorio, so), así que:
    • Bar crea Bim
    • Bar hace algo

Usando inyección de dependencia

Así es como funciona un código usando DI:

• La aplicación necesita Foo, que necesita Bar, que necesita Bim, así que:
• La aplicación crea Bim
• La aplicación crea Bar y le da Bim
• La aplicación crea Foo y le da Bar
• Llamadas de aplicación Foo
  • Foo llama a Bar
    • Bar hace algo

El control de las dependencias se invierte de una llamada a la que llama.

¿Qué problemas resuelve?

La inyección de dependencias facilita el intercambio con las diferentes implementaciones de las clases inyectadas. Durante las pruebas unitarias puede inyectar una implementación ficticia, lo que hace que las pruebas sean mucho más fáciles.

Ex: Supongamos que su aplicación almacena el archivo subido por el usuario en la unidad de Google, con DI su código de controlador puede tener este aspecto:

class SomeController
{
    private $storage;

    function __construct(StorageServiceInterface $storage)
    {
        $this->storage = $storage;
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

class GoogleDriveService implements StorageServiceInterface
{
    public function authenticate($user) {}
    public function putFile($file) {}
    public function getFile($file) {}
}

Cuando tus requisitos cambian, por ejemplo, en lugar de GoogleDrive se te pide que uses Dropbox. Solo necesitas escribir una implementación de dropbox para StorageServiceInterface. No tienes que realizar ningún cambio en el controller siempre y cuando la implementación de Dropbox se adhiera a la interfaz StorageServiceInterface.

Durante la prueba, puede crear el simulacro para el StorageServiceInterface con la implementación ficticia donde todos los métodos devuelven null (o cualquier valor predefinido según su requisito de prueba).

En su lugar, si tuviera la clase controller para construir el objeto de almacenamiento con la palabra clave new de esta manera:

class SomeController
{
    private $storage;

    function __construct()
    {
        $this->storage = new GoogleDriveService();
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

Cuando desee cambiar con la implementación de Dropbox, debe reemplazar todas las líneas donde se construye el objeto new GoogleDriveService y usar el DropboxService. Además al probar la clase SomeController el constructor siempre espera que se active la clase GoogleDriveService y los métodos reales de esta clase.

¿Cuándo es apropiado y cuándo no? En mi opinión se usa DI cuando se piensa que hay (o puede haber) implementaciones alternativas de una clase.

Inversion of control es cuando vas a la tienda de comestibles y tu esposa te da la lista de productos para comprar.

En términos de programación, pasó una función de devolución de llamada getProductList() a la función que está ejecutando doShopping();

Permite al usuario de la función definir algunas partes de la misma haciéndola más flexible.

Una explicación escrita muy simple se puede encontrar aquí

Http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html

Dice:

" Cualquier aplicación no trivial se compone de dos o más clases que colaborar entre sí para llevar a cabo alguna lógica de negocio. Tradicionalmente, cada objeto es responsable de obtener su propio referencias a los objetos con los que colabora (sus dependencias). Al aplicar DI, los objetos son dadas sus dependencias en la creación tiempo por alguna entidad externa que coordina cada objeto en el sistema. En otras palabras, las dependencias se inyectan en los objetos."

Programación hablando

IoC en términos fáciles: Es el uso de la Interfaz como una forma de algo específico (como un campo o un parámetro) como un comodín que puede ser utilizado por algunas clases. Permite la reutilización del código.

Por ejemplo, supongamos que tenemos dos clases : Perro y Gato. Ambos comparten las mismas cualidades / estados: edad, tamaño, peso. Así que en lugar de crear una clase de servicio llamada DogService y CatService, puedo crear un una única llamada AnimalService que permite utilizar Perros y Gatos solo si utilizan la interfaz IAnimal .

Sin embargo, pragmáticamente hablando, tiene algo al revés.

A) la Mayoría de los desarrolladores no saben cómo usarlo. Por ejemplo, puedo crear una clase llamada Customer y Puedo crear automáticamente (usando las herramientas del IDE) una interfaz llamada ICustomer. Por lo tanto, no es raro encontrar una carpeta llena de clases y interfaces, no importa si las interfaces serán reutilizadas o no. Se llama HINCHAZÓN. Algunas personas podrían argumentar que "puede ser en el futuro podríamos usarlo". :-|

B) Tiene algunos límites. Por ejemplo, hablemos del caso de Dog y Cat y quiero agregar un nuevo servicio (funcionalidad) solo para perros. Digamos que quiero calcular el número de días que necesito para entrenar a un perro (trainDays()), para el gato es inútil, los gatos no pueden ser entrenados (estoy bromear).

B. 1) Si añado trainDays() al Servicio AnimalService entonces también funciona con cats y no es válido en absoluto.

B. 2) Puedo agregar una condición en trainDays() donde evalúa qué clase se usa. Pero romperá completamente el CoI.

B. 3) Puedo crear una nueva clase de servicio llamada DogService solo para la nueva funcionalidad. Pero, aumentará la capacidad de mantenimiento del código porque tendremos dos clases de servicio (con funcionalidad similar) para Perro y es malo.

La inversión de control es un principio genérico, mientras que la Inyección de dependencias realiza este principio como un patrón de diseño para la construcción de grafos de objetos (es decir, la configuración controla cómo los objetos se hacen referencia entre sí, en lugar de que el propio objeto controle cómo obtener la referencia a otro objeto).

Mirando la Inversión de Control como un patrón de diseño, necesitamos mirar lo que estamos invirtiendo. La inyección de dependencias invierte el control de la construcción de un gráfico de objetos. Si dicho en términos sencillos, la inversión del control implica un cambio en el flujo de control en el programa. Eg. En la aplicación independiente tradicional, tenemos el método principal, desde donde el control se pasa a otras bibliotecas de terceros(en caso, hemos utilizado la función de la biblioteca de terceros), pero a través de la inversión del control el control se transfiere desde el código de la biblioteca de terceros a nuestro código, ya que estamos tomando el servicio de la biblioteca de terceros. Pero hay otros aspectos que necesitan ser invertidos dentro de un programa - por ejemplo, invocación de métodos e hilos para ejecutar el código.

Para aquellos interesados en una mayor profundidad en la Inversión de Control, se ha publicado un documento que describe una imagen más completa de la Inversión de Control como un patrón de diseño (OfficeFloor: using office patterns to improve software design http://doi.acm.org/10.1145/2739011.2739013 con una copia gratuita disponible para descargar desde http://www.officefloor.net/mission.html )

Lo que se identifica es lo siguiente relación:

Inversión del Control (para métodos) = Inyección de Dependencia (estado) + Inyección de Continuación + Inyección de Hilo

Me gusta esta explicación: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

Comienza simple y muestra ejemplos de código también.

El consumidor, X, necesita la clase consumida, Y, para lograr algo. Eso es todo bueno y natural, pero X realmente necesita saber que utiliza Y?

¿No es suficiente que X sepa que usa algo que tiene el comportamiento, los métodos, las propiedades, etc., de Y ¿sin saber quién realmente implementa el comportamiento?

Extrayendo una definición abstracta del comportamiento utilizado por X en Y, ilustrado como I a continuación, y dejando que el consumidor X use una instancia de eso en lugar de Y, puede continuar haciendo lo que hace sin tener que conocer los detalles sobre Y.

En la ilustración anterior Y implementa I y X usa una instancia de I. Aunque es muy posible que X todavía use Y lo interesante es que X no que lo sepas. Solo sabe que utiliza algo que implementa I.

Lea el artículo para más información y descripción de beneficios tales como:

• X ya no depende de Y
• Más flexible, la implementación se puede decidir en tiempo de ejecución
• Aislamiento de la unidad de código, pruebas más fáciles

...

Entiendo que la respuesta ya se ha dado aquí. Pero sigo pensando que algunos conceptos básicos sobre la inversión del control tienen que ser discutidos aquí en detalle para futuros lectores.

La Inversión de Control (CoI) se ha construido sobre un principio muy simple llamado Principio de Hollywood. Y dice que

No nos llames, te llamaremos

Lo que significa es que no vayas a Hollywood para cumplir tu sueño más bien si eres digno entonces Hollywood te encontrará y hará que tu sueño se haga realidad. Bastante invertida, ¿eh?

Cuando discutimos sobre el principio del CoI, solemos olvidarnos de Hollywood. Para el CoI, tiene que haber tres elementos, un Hollywood, usted y una tarea como cumplir su sueño.

En nuestro mundo de la programación, Hollywood representan un marco genérico (puede ser escrito por usted o por otra persona), usted representa el código de usuario que escribió y la tarea representa lo que desea cumple con tu código. Ahora usted nunca va a desencadenar su tarea por sí mismo, no en el CoI! Más bien ha diseñado todo de tal manera que su marco activará su tarea para usted. Por lo tanto, ha construido un marco reutilizable que puede hacer de alguien un héroe u otro un villano. Pero ese marco siempre está a cargo, sabe cuándo elegir a alguien y ese alguien solo sabe lo que quiere ser.

Un ejemplo de la vida real sería dado aquí. Supongamos que desea desarrollar una web aplicación. Por lo tanto, crea un marco que manejará todas las cosas comunes que una aplicación web debe manejar, como manejar la solicitud http, crear el menú de la aplicación, servir páginas, administrar cookies, activar eventos, etc.

Y luego deja algunos ganchos en su marco donde puede poner más códigos para generar menús personalizados, páginas, cookies o registrar algunos eventos de usuario, etc. En cada solicitud del navegador, su marco se ejecutará y ejecutará sus códigos personalizados si está enganchado y luego lo servirá de nuevo al navegador.

Entonces, la idea es bastante simple. En lugar de crear una aplicación de usuario que controlará todo, primero crea un marco reutilizable que controlará todo, luego escribe tus códigos personalizados y lo engancha al marco para ejecutarlos a tiempo.

Laravel y EJB son ejemplos de tal marco.

Referencia:

Https://martinfowler.com/bliki/InversionOfControl.html

Https://en.wikipedia.org/wiki/Inversion_of_control

La inversión de control consiste en transferir el control de la biblioteca al cliente. Tiene más sentido cuando hablamos de un cliente que inyecta (pasa) un valor de función (expresión lambda) en una función de orden superior (función de biblioteca) que controla (cambia) el comportamiento de la función de biblioteca. Un cliente o marco de trabajo que inyecta dependencias de bibliotecas (que llevan el comportamiento) en las bibliotecas también se puede considerar IoC

1. Así que número 1 arriba . ¿Qué es la Inversión de Control?

2. El mantenimiento es la cosa número uno que resuelve para mí. Garantiza que estoy usando interfaces para que dos clases no sean íntimas entre sí.

Al usar un contenedor como Castle Windsor, resuelve los problemas de mantenimiento aún mejor. Poder intercambiar un componente que va a una base de datos por uno que usa persistencia basada en archivos sin cambiar una línea de código es impresionante (cambio de configuración, ya está).

Y una vez que te metes en los genéricos, se pone aún mejor. Imagine tener un editor de mensajes que recibe registros y publica mensajes. No le importa lo que publica, pero necesita un mapeador para llevar algo de un registro a un mensaje.

public class MessagePublisher<RECORD,MESSAGE>
{
    public MessagePublisher(IMapper<RECORD,MESSAGE> mapper,IRemoteEndpoint endPointToSendTo)
    {
      //setup
    }
}

Lo escribí una vez, pero ahora puedo inyectar muchos tipos en este conjunto de código si publico diferentes tipos de mensajes. También puedo escribir mapeadores que toman un registro del mismo tipo y mapa ellos a diferentes mensajes. El uso de DI con genéricos me ha dado la capacidad de escribir muy poco código para realizar muchas tareas.

Oh sí, hay problemas de testabilidad, pero son secundarios a los beneficios del CoI/DI.

Definitivamente me encanta el CoI/DI.

3 . Se vuelve más apropiado en el momento en que tiene un proyecto de tamaño mediano de algo más complejidad. Yo diría que es apropiado en el momento en que empiezas a sentir dolor.

La creación de un objeto dentro de la clase se llama acoplamiento apretado, Spring elimina esta dependencia siguiendo un patrón de diseño(DI/IOC). En qué objeto de clase se pasa en constructor en lugar de crear en clase. Más sobre damos la variable de referencia de super clase en constructor para definir una estructura más general.

Para entender el concepto, la Inversión de Control (IoC) o el Principio de Inversión de Dependencia (DIP) implica dos actividades: abstracción e inversión. La inyección de dependencia (DI) es solo uno de los pocos métodos de inversión.

Para leer más sobre esto puedes leer mi blog Aquí

1. ¿Qué es?

Es una práctica en la que se deja que el comportamiento real provenga de fuera del límite (Clase en Programación Orientada a Objetos). La entidad límite solamente conoce la abstracción (por ejemplo, interfaz, clase abstracta, delegar en Programación Orientada a Objetos) de la misma.

1. ¿Qué problemas resuelve?

En términos de programación, el CoI intenta resolver código monolítico haciéndolo modular, desacoplando varias partes del mismo y haciéndolo comprobable unitariamente.

1. ¿Cuándo es apropiado y cuándo no?

Es apropiado la mayor parte del tiempo, a menos que tenga una situación en la que solo desee un código monolítico (por ejemplo, muy simple program)

Usando IoC no estás haciendo nuevos objetos. Su contenedor IoC hará eso y administrará la vida útil de ellos.

Resuelve el problema de tener que cambiar manualmente cada instancia de un tipo de objeto a otro.

Es apropiado cuando tiene una funcionalidad que puede cambiar en el futuro o que puede ser diferente dependiendo del entorno o la configuración utilizada.