De acuerdo a la artículo escrito por Martin Fowler, la inversión de control es el principio donde el flujo de control de un programa es la inversa: en lugar de que el programador controlar el flujo de un programa, las fuentes externas (marco, los servicios, otros componentes) tomar el control de ella. Es como que enchufar algo en otra cosa. Mencionó un ejemplo acerca de EJB 2.0:

Por ejemplo, el Bean de Sesión de la interfaz de
define ejbRemove, ejbload
(almacenados en el almacenamiento secundario), y
ejbActivate (restaurado de pasivo
del estado). Usted no consigue controlar cuando
estos métodos son llamados, justo lo que
que hacen. El contenedor llama a nosotros,
no lo llame.

Esto nos lleva a la diferencia entre el marco y la biblioteca:

De inversión de Control es una parte clave de
¿qué hace que un marco diferente a un
biblioteca. Una biblioteca es esencialmente un
conjunto de funciones que se pueden llamar,
estos días, por lo general organizados en
clases. Cada llamada que hace un poco de trabajo y
devuelve el control al cliente.

Creo, el punto de vista de que el DI es del COI, significa que la dependencia de un objeto es la inversa: en vez controla sus propias dependencias, ciclo de vida… otra cosa no es para usted. Pero, como usted me dijo acerca de DI por manos, DI no es necesariamente COI. Podemos tener la DI y no hay COI.

Sin embargo, en este artículo (a partir de la pococapsule, otro COI Marco para C/C++), se sugiere que la causa de IOC y DI, los contenedores IOC y DI marcos son mucho más superiores a J2EE, desde J2EE mezcla el marco de código en los componentes, por lo tanto no se lo que es Plain Old Java/C++ del Objeto (POJO/POCO).

Contenedores de Inversión de Control distinta de la Dependencia patrón de Inyección (Enlace del archivo)

Adicional de lectura para entender lo que es el problema con el antiguo Componente de Desarrollo Basado en el Framework, que nos lleva a la segunda papel por encima de: ¿por Qué y para qué de la Inversión de Control (enlace del Archivo)

Mi Pregunta: ¿Qué es exactamente el IOC y DI? Estoy confundido. Basado en pococapsule, COI es algo más importante que sólo invertir el control entre los objetos o los programadores y los marcos.

  • He aquí una buena valoración crítica sobre el tema, Coi vs DI (Dependencia Inyectar) vs SL (Service Locator): tinyurl.com/kk4be58 – Extracto de la url: Coi vs DI (Inyección de dependencias)? La coi es el concepto general, donde el control de flujo se invierte desde el código de cliente a marco, que «Hace algo para el cliente». SL (Localizador de Servicio) y DI (Inyección de dependencias) son dos de los patrones de diseño se originan fuera de la Coi.
  • Añadir mi granito de arena, si uno está interesado en cómo la inyección de dependencia puede ser útil en una tienda de café tema, he escrito un artículo sobre esto aquí: digigene.com/design-patterns/dependency-injection-coffeeshop
  • El pocomatic enlaces están rotos
  • decente artículo para principiantes asimplify.com/dependency-injection-inversion-control
  • La inversión de dependencia: Depende de abstracciones, no en concreciones. La inversión de control: Principal vs Abstracción, y cómo el Principal es el «pegamento» de los sistemas. Estos son algunos buenos posts hablando de esto: coderstower.com/2019/03/26/… coderstower.com/2019/04/02/… coderstower.com/2019/04/09/…
InformationsquelleAutor Amumu | 2011-07-01

20 Comentarios

  1. 575

    Coi es un término genérico que significa que en lugar de tener la llamada de la aplicación de los métodos en un marco, el marco de llamadas, implementaciones de proporcionada por la aplicación.

    DI es una forma de la Coi, donde implementaciones se pasa en un objeto a través de constructores/incubadoras/servicio de búsquedas, que el objeto ‘dependen’ en el fin de comportarse correctamente.

    Coi sin el uso de DI, por ejemplo, sería la Plantilla de patrón debido a que la aplicación sólo puede ser cambiado a través de los sub-classing.

    DI Marcos están diseñados para hacer uso de DI y se puede definir interfaces (o Anotaciones en Java) para facilitar el paso en las implementaciones.

    Contenedores IoC son DI marcos que puedan trabajar fuera del lenguaje de programación. En algunos se puede configurar que las implementaciones de utilizar en los archivos de metadatos (por ejemplo, XML), que son menos invasivas. Con algunos se puede hacer de la Coi que normalmente sería imposible como inyectar una aplicación en pointcuts.

    Ver también este Martin Fowler artículo.

    • Gracias por la respuesta. Pero el papel de otro sugiere que con la COI, los contenedores IOC son mucho más superiores a EJB, mientras que Martin Fowler sugiere que los EJB es un ejemplo típico de la COI.
    • EJB de gestión es realmente un ejemplo típico de la Coi. Se puede ver desde el hecho de que el ciclo de vida de un EJB es gestionada por el contenedor, no por el programador. El programador no crear o destruir un EJB ejemplo, porque el control se delega en el servidor. Ese es el concepto de la Coi: el código externo de los controles cuando el código se llama, que es generalmente el inversa de lo que hace la mayoría del tiempo.
    • Coi es un término genérico que significa que en lugar de tener la llamada de la aplicación de los métodos en un marco, el marco de llamadas, implementaciones de proporcionada por la aplicación. Puede usted explicar más acerca de esto ?
    • También conocido como Hollywood principio, ‘no nos llame, nosotros lo llamaremos’. Las hojas de la invocación hasta el marco en lugar de la aplicación.
    • sería mejor leer el artículo que Garrett adjunto, que es una discusión detallada acerca de la inversión del control de la aplicación del código de marco.
    • de qué tema hacer pointcuts caer bajo? preguntar para averiguar más acerca de la terminología relacionada, primera vez que oigo hablar de esto y he estado leyendo algo que yo pueda tener en mis manos
    • usted puede comprobar fuera de la wiki-link, algunos idiomas tienen marcos especiales para añadir punto de recortes de otras lenguas, los han incorporado.
    • este artículo, menciona que «El punto clave de la Coi es independiente de toma de decisiones de código (cuando para hacer algo) del código de la acción (qué hacer cuando ocurre algo)». Es esto cierto, o el artículo no hace un buen trabajo explicando Coi correctamente?

  2. 194

    En resumen, Coi es un término más amplio que incluye, pero no está limitado a, DI

    El plazo de Inversión de Control (IoC) originalmente se refería a cualquier tipo de estilo de programación, donde un general
    marco de ejecución o de tiempo controla el flujo del programa

    Antes de DI tenía un nombre, la gente empezó a referirse a los marcos de gestionar las Dependencias de la Inversión
    de Control de Contenedores, y de pronto, el significado de la Coi poco a poco se desvió hacia ese significado particular: la Inversión de Control sobre las Dependencias.

    De inversión de Control (Coi) significa que los objetos no crear otros objetos sobre los que se basan para hacer su trabajo. En su lugar, obtiene los objetos que necesitan de una fuente externa (por ejemplo, un archivo de configuración xml).

    La Inyección de dependencia (DI) significa que esto se hace sin que el objeto de la intervención, generalmente por un componente de marco que pasa los parámetros del constructor y de conjunto de propiedades.

    • Parece Coi es sólo otro término para la Depency principio de la Inversión, no?
    • Sí, creo que la Coi y la INMERSIÓN son la misma cosa. DIP y DI no son la misma cosa. Coi se puede hacer sin DI, pero DI no puede hacerse sin el Coi.
    • No, DIP y el Coi no son sinónimos y no están relacionadas.
    • Ja, que por eso estoy aquí en este hilo… «Inversión de Control vs Inyección de Dependencia»
  3. 43

    DI es un subconjunto de la Coi

    • Coi significa que los objetos no crear otros objetos sobre los que se basan para hacer su trabajo. En su lugar, obtiene los objetos que necesitan de un servicio externo (por ejemplo, archivo xml o una sola aplicación de servicio). 2 implementaciones de la Coi, yo la uso, son DI y ServiceLocator.
    • DI significa que el Coi principio de obtener dependiente de objeto se realiza sin el uso de objetos concretos, sino abstracciones (interfaces). Esto hace que todos los componentes de la cadena de comprobables, causa el aumento en el nivel de componentes no dependen de menor nivel de componente, sólo a partir de la interfaz. Se burla de implementar estas interfaces.

    Aquí están algunas otras técnicas para lograr Coi.

    • Yo no diría que el Coi no significa la creación de objetos. Cuando llame no método de la clase directamente, pero el método de interfaz – esta es la inversión de control (como en este caso la persona que llama no dependen de código de llamada) y no está relacionado con la creación de objetos en todo. Un ejemplo más de la Coi son los eventos y delegados
  4. 33

    La inversión de Control vs Inyección de Dependencia

    fuente

    Coi (menversion of Control de) :- Es un término genérico y aplicado en varias formas (eventos, delegados, etc).

    DI (Dependency menjection) :- DI es un sub-tipo de la Coi y es implementado por inyección de constructor, instalador de la inyección o de la Interfaz de inyección.

    Pero, Primavera sólo admite los dos tipos siguientes :

    • Setter Inyección
      • Setter basado DI se realiza llamando a métodos setter en los frijoles después de invocar un constructor sin argumentos o no-argumento estático de fábrica método para crear instancias de sus bean.
    • Inyección De Constructor
      • Constructor basado DI se realiza mediante la invocación de un constructor con un número de argumentos, cada uno representando un colaborador.Mediante este podemos validar que la inyección de frijoles no son nulos y fallar rápido(error en tiempo de compilación y no en tiempo de ejecución), por lo que al iniciar la aplicación en sí conseguimos NullPointerException: bean does not exist. Inyección de Constructor es la Mejor práctica para inyectar las dependencias.
    • no es correcto afirmar que la Primavera no admite la propiedad de la inyección. Es lo que hace. Y es una mala práctica, estoy de acuerdo.
  5. 15

    IOC (Inversion Of Control): da el control del contenedor para obtener una instancia del objeto se denomina Inversión de Control., significa que en lugar de crear un objeto con el operador new, deje que el recipiente de hacer eso por usted.

    DI (Inyección de dependencias): el Camino de la inyección de propiedades a un objeto se denomina inyección de Dependencia.

    We have three types of Dependency injection
        1)  Constructor Injection
        2)  Setter/Getter Injection
        3)  Interface Injection
    

    Primavera sólo son compatibles con Inyección de Constructor y Setter/Getter de la Inyección.

  6. 10

    Ya que todas las respuestas hincapié en la teoría, me gustaría demostrar con un ejemplo del primer enfoque:

    Supongamos que estamos construyendo una aplicación que contiene una función para enviar SMS mensajes de confirmación una vez que el pedido ha sido enviado.
    Vamos a tener dos clases, uno de ellos es responsable por el envío de SMS (SMSService), y otro responsable de la captura de entradas del usuario (UIHandler), nuestro código será como a continuación:

    public class SMSService
    {
        public void SendSMS(string mobileNumber, string body)
        {
            SendSMSUsingGateway(mobileNumber, body);
        }
    
        private void SendSMSUsingGateway(string mobileNumber, string body)
        {
            /*implementation for sending SMS using gateway*/
        }
    }
    
    public class UIHandler
    {
        public void SendConfirmationMsg(string mobileNumber)
        {
            SMSService _SMSService = new SMSService();
            _SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
        }
    }
    

    Por encima de la implementación no está mal, pero hay algunos problemas:

    -) Supongo que En el entorno de desarrollo, de la que desea guardar los Sms enviados a un archivo de texto en lugar de usar la puerta de enlace de SMS, para lograr esto; vamos a terminar de cambiar la aplicación concreta de (SMSService) con otra aplicación, estamos perdiendo la flexibilidad y la obligó a reescribir el código, en este caso.

    -) Vamos a terminar de mezclar las responsabilidades de las clases, nuestro (UIHandler) nunca debería saber acerca de la aplicación concreta de (SMSService), esto debe ser hecho fuera de las clases con los «Interfaces». Cuando esto se lleva a la práctica, nos dará la capacidad de cambiar el comportamiento del sistema mediante el intercambio (SMSService) se usa con otro simulacro de servicio que implementa la misma interfaz, este servicio será guardar mensajes de texto a un archivo de texto en lugar de enviar a mobileNumber.

    Para solucionar los problemas anteriores, utilizamos Interfaces que serán implementadas por los nuestros (SMSService) y el nuevo (MockSMSService), básicamente, la nueva Interfaz (ISMSService) expondrá los mismos comportamientos, tanto de servicios como el código de abajo:

    public interface ISMSService
    {
        void SendSMS(string phoneNumber, string body);
    }
    

    A continuación, vamos a cambiar nuestro (SMSService) implementación para implementar la (ISMSService) interfaz:

    public class SMSService : ISMSService
    {
        public void SendSMS(string mobileNumber, string body)
        {
            SendSMSUsingGateway(mobileNumber, body);
        }
    
        private void SendSMSUsingGateway(string mobileNumber, string body)
        {
            /*implementation for sending SMS using gateway*/
            Console.WriteLine("Sending SMS using gateway to mobile: 
            {0}. SMS body: {1}", mobileNumber, body);
        }
    }
    

    Ahora vamos a ser capaces de crear nuevas burlarse de servicio (MockSMSService) totalmente diferentes de aplicación, con la misma interfaz:

    public class MockSMSService :ISMSService
    {
        public void SendSMS(string phoneNumber, string body)
        {
            SaveSMSToFile(phoneNumber,body);
        }
    
        private void SaveSMSToFile(string mobileNumber, string body)
        {
            /*implementation for saving SMS to a file*/
            Console.WriteLine("Mocking SMS using file to mobile: 
            {0}. SMS body: {1}", mobileNumber, body);
        }
    }
    

    A este punto, podemos cambiar el código en (UIHandler) para el uso de la aplicación concreta del servicio (MockSMSService) fácilmente de la siguiente manera:

    public class UIHandler
    {
        public void SendConfirmationMsg(string mobileNumber)
        {
            ISMSService _SMSService = new MockSMSService();
            _SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
        }
    }
    

    Hemos logrado una gran flexibilidad y una implementado la separación de los problemas en nuestro código, pero todavía tenemos que hacer un cambio en la base de código para cambiar entre los dos Servicios de SMS. Así que necesitamos implementar la Inyección de Dependencia.

    Para lograr esto, es necesario implementar un cambio a nuestra (UIHandler) constructor de la clase para pasar de la dependencia a través de ella, haciendo esto, el código que utiliza el (UIHandler) puede determinar que la aplicación concreta de (ISMSService) para usar:

    public class UIHandler
    {
        private readonly ISMSService _SMSService;
    
        public UIHandler(ISMSService SMSService)
        {
            _SMSService = SMSService;
        }
    
        public void SendConfirmationMsg(string mobileNumber)
        {
            _SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
        }
    }
    

    Ahora la interfaz de usuario de forma que se hable con la clase (UIHandler) es la responsable de aprobar la ejecución de la interfaz (ISMSService) para consumir. Esto significa que hemos invertido el control, la (UIHandler) ya no es responsable de decidir que la aplicación a utilizar, el código de llamada sí. Hemos implementado el de Inversión de Control principio de que el DI es un tipo de la misma.

    La interfaz de usuario código del formulario será de la siguiente manera:

    class Program
    {
        static void Main(string[] args)
        {
            ISMSService _SMSService = new MockSMSService(); //dependency
    
            UIHandler _UIHandler = new UIHandler(_SMSService);
            _UIHandler.SendConfirmationMsg("96279544480");
    
            Console.ReadLine();
        }
    }
    
    • Gran explicación
  7. 5

    Pero la primavera documentación dice que son los mismos.

    http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-introduction

    En la primera línea «Coi es también conocida como la inyección de dependencias (DI)«.

    • Supongo que lo que estaban tratando de dirección es que el DI es una muy ampliamente utilizado sabor de la Coi patrón de diseño que casi se puede fácilmente ser llamado Coi también conocido como DI – a menos que la documentación tiene ninguna referencia explícita que sugieren lo contrario.
    • «El coi es también conocida como la inyección de dependencias (DI)» … horsefeathers!
  8. 5

    Coi – Inversión de control es un término genérico, independiente de la lengua, en realidad no es crear los objetos sino que describen en el que la moda objeto que se crea.

    DI – la Inyección de Dependencia es de hormigón plazo, en el que nos ofrecen las dependencias del objeto en tiempo de ejecución mediante el uso de diferentes técnicas de inyección de viz. Setter de la Inyección, Inyección de Constructor o por Interfaz de la Inyección.

  9. 4

    De inversión de control es un paradigma de diseño con el objetivo de dar más control el objetivo de los componentes de la aplicación, las que hacer el trabajo.

    La inyección de dependencia es un patrón que se usa para crear instancias de objetos que otros objetos dependen sin saber a la hora de compilar la clase que se utilizará para proporcionar esa funcionalidad.

    Existen varias técnicas para implementar la inversión de control. Estos son:

    • El uso de un patrón de fábrica
    • El uso de un servicio de localizador de patrón
    • El uso de una inyección de dependencia de cualquier abajo: tipo:

      1). Una inyección de constructor

      2). Un setter de inyección

      3). Una interfaz de inyección

  10. 2

    COI indica que un externo de clases de la gestión de las clases de una aplicación,y externos de clases significa un contenedor maneja la dependencia entre la clase de aplicación.
    concepto básico de COI es que el programador no necesita para crear sus objetos, sino que describen cómo deben ser creados.

    Las principales tareas que realiza el contenedor de IoC son:
    para crear una instancia de la clase de la aplicación. para configurar el objeto. para ensamblar las dependencias entre los objetos.

    DI es el proceso de proporcionar a las dependencias de un objeto en tiempo de ejecución mediante el uso de incubadora de inyección o de inyección de constructor.

  11. 2

    IOC (Inversion of Control) es básicamente el patrón de diseño de concepto de eliminación de dependencias y la disociación de ellos para hacer que el flujo no lineal , y dejar que el contenedor /o de otra entidad gestionar el aprovisionamiento de las dependencias. Realmente siga Hollywood del director de «no nos llame, le llamaremos».
    Así que resumiendo las diferencias.

    De inversión de control :- Es un término genérico para desarticular a las dependencias y delegar su aprovisionamiento , y esto se puede implementar de varias maneras (eventos, delegados, etc).

    Inyección de dependencia :- DI es un subtipo de la COI y es ejecutado por inyección de constructor, instalador de inyección o el método de la inyección.

    El siguiente artículo describe esta muy cuidadosamente.

    https://www.codeproject.com/Articles/592372/Dependency-Injection-DI-vs-Inversion-of-Control-IO

  12. 2

    De inversión de Control es un genérico principio de diseño de arquitectura de software que ayuda en la creación reutilizables, software modular marcos que son fáciles de mantener.

    Es un principio de diseño en el que el Flujo de Control es «recibido» de los genéricos-escrito de la biblioteca o de código reutilizable.

    Para entenderlo mejor, vamos a ver cómo podemos utilizar para el código en nuestros días anteriores de codificación. En el procedimiento/de los lenguajes tradicionales, la lógica de negocio generalmente controla el flujo de la aplicación y «Llama» el genérico o el código reutilizable/funciones. Por ejemplo, en una sencilla aplicación de Consola, mi flujo de control es controlado por mi instrucciones del programa, que puede incluir las llamadas a algunos generales reutilizables funciones.

    print ("Please enter your name:");
    scan (&name);
    print ("Please enter your DOB:");
    scan (&dob);
    
    //More print and scan statements
    <Do Something Interesting>
    
    //Call a Library function to find the age (common code)
    print Age
    

    En Contraste, con el Coi, los Marcos son el código reutilizable que se «Llama» la lógica de negocio.

    Por ejemplo, en un sistema basado en windows, un marco ya se encuentra disponible para crear elementos de interfaz de usuario como botones, menús, ventanas y cuadros de diálogo. Cuando escribo la lógica de negocio de mi aplicación, no sería del marco de eventos que van a llamar a mi la lógica de negocio de código (cuando se activa un evento) y NO al contrario.

    A pesar de que, en el marco del código no es consciente de la lógica de negocios, todavía saber cómo llamar a mi código. Esto se logra mediante eventos/delegados, las devoluciones de llamada, etc. Aquí el Control de flujo es «Invertida».

    Así, en lugar de en función del flujo de control en objetos enlazados estáticamente, el flujo depende de la general gráfico de objetos y las relaciones entre los diferentes objetos.

    La Inyección de dependencia es un patrón de diseño que implementa Coi principio para resolver las dependencias de objetos.

    En palabras más simples, cuando usted está tratando de escribir el código, usted será la creación y el uso de diferentes clases. Una clase (Clase a) puede utilizar otras clases (Clase B y/o D). Así, las de Clase B y D son dependencias de la clase A.

    Una simple analogía será una clase de Coche. Un coche puede depender de otras clases como el Motor, los Neumáticos y más.

    La Inyección de dependencia sugiere que, en lugar de las clases Dependientes (de la Clase de Coche) para la creación de sus dependencias (Motor de Clase y de la clase de los Neumáticos), la clase debe ser inyectado con el ejemplo concreto de la dependencia.

    Permite entender con un ejemplo práctico. Considere la posibilidad de que usted está escribiendo su propio Editor de texto. Entre otras cosas, usted puede tener un corrector ortográfico que proporciona al usuario una instalación para comprobar los errores en su texto. Una simple aplicación de dicho código puede ser:

    Class TextEditor
    {
    
        //Lot of rocket science to create the Editor goes here
    
        EnglishSpellChecker objSpellCheck;
        String text;
    
        public void TextEditor()
    
        {   
    
            objSpellCheck = new EnglishSpellChecker();
    
        }
    
        public ArrayList <typos> CheckSpellings()
        {
    
            //return Typos;
    
        }
    
    }
    

    A primera vista, todo parece de color de rosa. El usuario escribe un texto. El desarrollador va a capturar el texto y llamar a la CheckSpellings función y podrá encontrar una lista de los errores Tipográficos que va a mostrar al Usuario.

    Todo parece un gran trabajo hasta que un buen día cuando un usuario empieza a escribir en francés en el Editor.

    Para proporcionar el soporte para más idiomas, tenemos que tener más SpellCheckers. Probablemente francés, alemán, español, etc.

    Aquí, hemos creado una muy acoplada código con el «inglés»corrector ortográfico está estrechamente unida con nuestro Editor de texto de clase, lo que significa que nuestro Editor de texto de la clase depende de la EnglishSpellChecker o en otras palabras EnglishSpellCheker es la dependencia para el Editor de texto. Tenemos que eliminar esta dependencia. Además, Nuestro Editor de Texto necesita una manera de mantener el hormigón de referencia de cualquier Corrector Ortográfico basado en la discreción del promotor en tiempo de ejecución.

    Así que, como vimos en la introducción de DI, se sugiere que la clase debe ser inyectado con sus dependencias. Así pues, debe ser el código de llamada a la responsabilidad para inyectar todas las dependencias de la llamada clase/código. Por lo que podemos reestructurar nuestro código, como

    interface ISpellChecker
    {
    
        Arraylist<typos> CheckSpelling(string Text);
    
    }
    
    Class EnglishSpellChecker : ISpellChecker
    
    {
    
        public override Arraylist<typos> CheckSpelling(string Text)
    
        {
    
            //All Magic goes here.
    
        }
    
    }
    
    
    
    Class FrenchSpellChecker : ISpellChecker
    
    {
    
        public override Arraylist<typos> CheckSpelling(string Text)
    
        {
    
            //All Magic goes here.
    
        }
    
    }
    

    En nuestro ejemplo, el Editor de texto de la clase debe recibir el hormigón instancia de ISpellChecker tipo.

    Ahora, la dependencia puede ser inyectado en el Constructor, un Público de la Propiedad o a un método.

    Vamos a tratar de cambiar nuestra clase utilizando el Constructor de DI. El cambio en el Editor de texto de la clase será algo parecido a:

    Class TextEditor
    
    {
    
        ISpellChecker objSpellChecker;
    
        string Text;
    
    
    
        public void TextEditor(ISpellChecker objSC)
    
        {
    
            objSpellChecker = objSC;
    
        }
    
    
    
        public ArrayList <typos> CheckSpellings()
    
        {
    
            return objSpellChecker.CheckSpelling();
    
        }
    
    }
    

    De modo que el código de llamada, mientras que la creación de el editor de texto se puede inyectar la adecuada corrector ortográfico de Tipo a la instancia del Editor de texto.

    Usted puede leer el artículo completo aquí

  13. 2

    DI y COI son dos patrón de diseño que principalmente se centra en la prestación de flojo acoplamiento entre los componentes, o simplemente una manera en la que podemos disociar la convencional de las relaciones de dependencia entre el objeto, de modo que los objetos no están apretados el uno al otro.

    Con los siguientes ejemplos, estoy tratando de explicar ambos conceptos.

    Previamente hemos escrito código como este

    Public MyClass{
     DependentClass dependentObject
     /*
      At somewhere in our code we need to instantiate 
      the object with new operator  inorder to use it or perform some method.
      */
      dependentObject= new DependentClass();
      dependentObject.someMethod();
    }
    

    Con la inyección de Dependencia, la dependencia del inyector se encargará de la creación de instancias de objetos

    Public MyClass{
     /* Dependency injector will instantiate object*/
     DependentClass dependentObject
    
     /*
      At somewhere in our code we perform some method. 
      The process of  instantiation will be handled by the dependency injector
     */
    
      dependentObject.someMethod();
    }
    

    El proceso anterior de dar el control a algunos otros (por ejemplo, el contenedor) para la creación de la instancia y de la inyección puede ser denominado como la Inversión de Control y el proceso en el cual el contenedor de IOC inyectar la dependencia para nosotros puede ser denominado como la inyección de dependencias.

    COI es el principio donde el flujo de control de un programa es la inversa: en lugar de que el programador controlar el flujo de un programa de, el programa controla el flujo mediante la reducción de los gastos generales para el programador.y el proceso utilizado por el programa para inyectar la dependencia que se denomina como DI

    Los dos conceptos de trabajo en conjunto que nos proporciona una manera de escribir mucho más flexible, reutilizable, y encapsulado de código, lo que las hace tan importantes conceptos en el diseño orientado a objetos soluciones.

    También Recomendamos la lectura.

    ¿Qué es la inyección de dependencias?

    También se puede comprobar que uno de mis similar respuesta aquí

    La diferencia entre la Inversión de Control & Inyección de Dependencia

  14. 1

    IOC(Inversion Of Control): da el control del contenedor para obtener la instancia de objeto se denomina Inversión de Control. Esto significa que en lugar de que son la creación de objetos de uso nuevo operador, deje que el recipiente de hacer eso por usted.

    DI(Inyección de dependencias): Pasar los parámetros necesarios(propiedades) de XML a un objeto(en CLASE POJO) se llama la inyección de Dependencia.

  15. 0

    Vamos a comenzar con la D de SÓLIDOS y mira DI e IoC de Scott Millett del libro «Profesional ASP.NET Patrones de Diseño»:

    Dependencia Principio de la Inversión (DIP)

    La DIP es todo acerca de aislar a sus clases de hormigón
    implementaciones y que ellos dependen de las clases abstractas o
    las interfaces. Promueve el mantra de codificación para una interfaz bastante
    de una aplicación, lo que aumenta la flexibilidad dentro de un sistema de
    asegurando que no están estrechamente acoplados a una aplicación.

    La Inyección de dependencias (DI) y de la Inversión de Control (IoC)

    Estrechamente vinculada a la DIP de la DI principio y el Coi principio. DI es el acto de suministrar un nivel bajo o dependiente de la clase a través de un
    constructor, el método o la propiedad. Se utiliza en conjunción con DI, estos
    dependiente de clases puede ser invertida para las interfaces o clases abstractas
    que llevará a flojamente acoplados a sistemas que son altamente comprobable y
    fácil de cambiar.

    En Coi, un flujo del sistema de control es invertida
    en comparación con la programación procedimental. Un ejemplo de esto es un Coi
    contenedor
    , cuya finalidad es la de inyectar a los servicios al cliente de código
    sin tener el código de cliente de la especificación de la aplicación concreta.
    El control en este caso que está siendo invertido, es la ley de la
    cliente de obtener el servicio.

    Millett,C (2010). Profesional ASP.NET los Patrones de Diseño. Wiley Publishing. 7-8.

  16. 0

    //ICO , DI ,10 años atrás , esta era la forma:

    public class  AuditDAOImpl implements Audit{
    
        //dependency
        AuditDAO auditDAO = null;
            //Control of the AuditDAO is with AuditDAOImpl because its creating the object
        public AuditDAOImpl () {
            this.auditDAO = new AuditDAO ();
        }
    }
    

    Ahora con la Primavera de 3, 4 o más recientes como la de abajo

    public class  AuditDAOImpl implements Audit{
    
        //dependency
    
         //Now control is shifted to Spring. Container find the object and provide it. 
        @Autowired
        AuditDAO auditDAO = null;
    
    }
    

    General, el control se invierte desde el viejo concepto de junto código para los marcos de trabajo como la Primavera que hace que el objeto esté disponible. De modo que la COI como lo que yo sé y la inyección de dependencias como usted sabe cuando se inyecta el dependiente de un objeto en otro objeto, usando el Constructor o incubadoras . Inyectar significa, básicamente, que pasa como un argumento. En primavera tenemos XML & anotación de configuración basada en donde se definen bean objeto y pasar el dependiente de un objeto con Constructor o setter inyección estilo.

  17. 0

    He encontrado mejor ejemplo en Dzone.com que es realmente útil para entender el verdadero diferentes entre IOC y DI

    «El coi es cuando tienes a alguien a crear objetos para usted.» Así que en lugar de escribir «nueva» palabra clave (Por ejemplo, MyCode c=new MyCode())en el código, el objeto es creado por alguien más. Ese ‘alguien’ es normalmente conocido como un contenedor de IoC. Esto significa que la entrega del rrsponsibility (control )en el contenedor para obtener la instancia de objeto se denomina Inversión de Control.,
    significa que en lugar de que son objeto mediante la creación de un nuevo operador, deje que el recipiente de hacer eso por usted.

       DI(Dependency Injection):  Way of injecting properties to an object is 
       called 
      Dependency injection.
       We have three types of Dependency injection
        1)  Constructor Injection
        2)  Setter/Getter Injection
        3)  Interface Injection
       Spring will support only Constructor Injection and Setter/Getter Injection.
    

    Leer artículo completo COI y Leer artículo Completo DI

  18. 0

    1) DI es Niño->obj depende de los padres-obj. El verbo depende es importante.
    2) la COI es Niño->obj realizar bajo una plataforma. donde la plataforma podría ser la escuela, el colegio, la clase de baile. Aquí realizar es una actividad con diferentes implicación en virtud de cualquier proveedor de la plataforma.

    ejemplo práctico:
    `

    //DI
    child.getSchool();
    //IOC
    child.perform()//is a stub implemented by dance-school
    child.flourish()//is a stub implemented by dance-school/school/
    

    `

    -AB

  19. 0

    Como para esta pregunta, yo diría que la wiki ya ha respondido de manera detallada y de fácil comprensión de las explicaciones. Me limitaré a citar las más importantes aquí.

    La implementación de la Coi

    En la programación orientada a objetos, hay varias técnicas básicas para
    implementar la inversión de control. Estos son:

    1. El uso de un servicio de localizador de patrón de Uso de la inyección de dependencia, para
      ejemplo de Constructor de inyección de inyección de Parámetro Definidor de la inyección
      La interfaz de la inyección;
    2. El uso de un contexto de búsqueda;
    3. Utilizando el método de plantilla patrón de diseño;
    4. Utilizando la estrategia patrón de diseño

    Como para La Inyección De Dependencia

    la inyección de dependencia es una técnica mediante la cual un objeto (o estática
    método) suministros de las dependencias de otro objeto. Una dependencia es
    un objeto que puede ser utilizado (un servicio). Una inyección es el paso de
    una dependencia a un objeto dependiente (un cliente) que lo utilizan.

  20. 0

    Coi concepto fue inicialmente escuchado durante el procedimiento de programación de la época. Por lo tanto, de un contexto histórico Coi habló acerca de la inversión de la propiedad de de control-flujo es decir, que posee la responsabilidad de invocar las funciones en el orden deseado – si se trata de las funciones propias o debe invertir a alguna entidad externa.

    Sin embargo una vez que la programación orientada a objetos surgido, la gente comenzó a hablar de la Coi en la programación orientada a objetos contexto donde las aplicaciones están relacionadas con la creación de objetos y sus relaciones, además de el flujo de control. Tales aplicaciones quería invertir la propiedad de creación de objetos (en lugar de control de flujo) y requiere un contenedor que es el responsable para la creación de objetos, objeto de ciclo de vida & inyección de dependencias de los objetos de la aplicación, eliminando los objetos de la aplicación, desde la creación de otro objeto concreto.

    En ese sentido, DI no es lo mismo que IoC, ya que no se trata de control de flujo, sin embargo, es una especie de Io*, es decir, la Inversión de la propiedad de creación de objetos.

    Lo que está mal en mi forma de explicativa DI e IoC?

Dejar respuesta

Please enter your comment!
Please enter your name here