dependency-injection - programacion - inyeccion de dependencias swift
Inversión de Control vs Inyección de Dependencia (18)
Según el documento escrito por Martin Fowler , la inversión de control es el principio donde se invierte el flujo de control de un programa: en lugar de que el programador controle el flujo de un programa, las fuentes externas (marco, servicios, otros componentes) toman el control de eso. Es como si enchufáramos algo en otra cosa. Mencionó un ejemplo sobre EJB 2.0:
Por ejemplo, la interfaz Session Bean define ejbRemove, ejbPassivate (almacenada en almacenamiento secundario) y ejbActivate (restaurada del estado pasivo). No puedes controlar cuándo se llaman estos métodos, solo lo que hacen. El contenedor nos llama, no lo llamamos.
Esto lleva a la diferencia entre el marco y la biblioteca:
La inversión de control es una parte clave de lo que hace que un marco sea diferente a una biblioteca. Una biblioteca es esencialmente un conjunto de funciones a las que puedes llamar, en estos días generalmente organizadas en clases. Cada llamada hace algún trabajo y devuelve el control al cliente.
Creo que el punto de vista de que DI es IOC, significa que la dependencia de un objeto está invertida: en su lugar, controla sus propias dependencias, el ciclo de vida ... otra cosa lo hace por usted. Pero, como me contaron acerca de DI con las manos, DI no es necesariamente IOC. Todavía podemos tener DI y no IOC.
Sin embargo, en este documento (de la pococapsule, otro marco de IOC para C / C ++), sugiere que debido a IOC y DI, los contenedores de IOC y los marcos de DI son mucho más superiores a J2EE, ya que J2EE mezcla el código de marco en los componentes , por lo tanto no lo hace Plain Old Java / C ++ Object (POJO / POCO).
Inversión de contenedores de control distintos del patrón de inyección de dependencia (enlace de archivo)
Lectura adicional para comprender cuál es el problema con el antiguo Marco de desarrollo basado en componentes, que conduce al segundo documento anterior: Por qué y qué de Inversión de control (enlace de archivo)
Mi pregunta : ¿Qué es exactamente IOC y DI? Estoy confundido. Basado en pococapsule, IOC es algo más importante que simplemente invertir el control entre objetos o programadores y marcos.
// ICO, DI, 10 años atrás, así fue:
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 Spring 3.4 o más reciente es como a continuación
public class AuditDAOImpl implements Audit{
//dependency
//Now control is shifted to Spring. Container find the object and provide it.
@Autowired
AuditDAO auditDAO = null;
}
En general, el control se invierte desde el antiguo concepto de código acoplado a los marcos como Spring, que hace que el objeto esté disponible. Así que eso es IOC, por lo que sé, y la inyección de dependencia, como usted sabe, cuando inyectamos el objeto dependiente en otro objeto utilizando Constructor o configuradores. Inyectar básicamente significa pasarlo como un argumento. En la primavera tenemos una configuración basada en XML y anotaciones donde definimos el objeto de bean y pasamos el objeto dependiente con el estilo de inyección de constructor o definidor.
1) DI es Child-> obj depende de padre-obj. El verbo depende es importante. 2) IOC is Child-> obj realizar bajo una plataforma. Donde la plataforma podría ser escuela, colegio, clase de baile. Aquí realizar es una actividad con diferentes implicaciones en cualquier proveedor de 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
Comencemos con la D de SOLID y observemos DI e IoC del libro de Scott Millett "Professional ASP.NET Design Patterns":
Principio de inversión de dependencia (DIP)
El DIP consiste en aislar sus clases de implementaciones concretas y hacer que dependan de clases o interfaces abstractas. Promueve el mantra de codificación a una interfaz en lugar de una implementación, lo que aumenta la flexibilidad dentro de un sistema al garantizar que no esté estrechamente vinculado a una implementación.
Inyección de dependencia (DI) e Inversión de control (IoC)
Muy vinculados al DIP están el principio DI y el principio IoC. DI es el acto de suministrar un nivel bajo o una clase dependiente a través de un constructor, método o propiedad. Utilizadas junto con DI, estas clases dependientes pueden invertirse en interfaces o clases abstractas que conducirán a sistemas acoplados de manera flexible que son altamente comprobables y fáciles de cambiar.
En IoC , el flujo de control de un sistema se invierte en comparación con la programación de procedimientos. Un ejemplo de esto es un contenedor IoC , cuyo propósito es inyectar servicios en el código del cliente sin tener el código del cliente especificando la implementación concreta. El control en este caso que se está invirtiendo es el acto del cliente que obtiene el servicio.
Millett, C (2010). Patrones de diseño profesional de ASP.NET. Publicación de Wiley. 7-8.
Como todas las respuestas enfatizan la teoría, me gustaría demostrarlo con un primer enfoque de ejemplo:
Supongamos que estamos creando una aplicación que contiene una función para enviar mensajes de confirmación de SMS una vez que se ha enviado el pedido. Tendremos dos clases, una es responsable de enviar el SMS (SMSService) y otra responsable de capturar las entradas de los usuarios (UIHandler), nuestro código se verá como se muestra 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!");
}
}
La implementación anterior no está mal, pero hay algunos problemas:
-) Supongamos que en el entorno de desarrollo, desea guardar los SMS enviados a un archivo de texto en lugar de usar la puerta de enlace de SMS, para lograrlo; Terminaremos cambiando la implementación concreta de (SMSService) con otra implementación, estamos perdiendo flexibilidad y forzados a volver a escribir el código en este caso.
-) Terminaremos mezclando responsabilidades de clases, nuestro (UIHandler) nunca debería saber acerca de la implementación concreta de (SMSService), esto debe hacerse fuera de las clases usando "Interfaces". Cuando esto se implemente, nos dará la posibilidad de cambiar el comportamiento del sistema intercambiando el (Servicio SMS) utilizado con otro servicio simulado que implementa la misma interfaz, este servicio guardará los SMS en un archivo de texto en lugar de enviarlos a MobileNumber.
Para solucionar los problemas anteriores, utilizamos Interfaces que serán implementadas por nuestro (SMSService) y el nuevo (MockSMSService), básicamente la nueva Interfaz (ISMSService) expondrá los mismos comportamientos de ambos servicios que el código a continuación:
public interface ISMSService
{
void SendSMS(string phoneNumber, string body);
}
Luego cambiaremos nuestra implementación (SMSService) para implementar la interfaz (ISMSService):
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 podremos crear un nuevo servicio de simulación (MockSMSService) con una implementación totalmente diferente utilizando 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);
}
}
En este punto, podemos cambiar el código en (UIHandler) para usar la implementación concreta del servicio (MockSMSService) 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 mucha flexibilidad e implementado la separación de inquietudes en nuestro código, pero aún debemos hacer un cambio en la base del código para cambiar entre los dos servicios de SMS. Por eso necesitamos implementar la inyección de dependencia .
Para lograr esto, necesitamos implementar un cambio en nuestro constructor de clase (UIHandler) para pasar la dependencia a través de él. Al hacer esto, el código que usa (UIHandler) puede determinar qué implementación concreta de (ISMSService) 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, el formulario de UI que hablará con la clase (UIHandler) es responsable de aprobar qué implementación de interfaz (ISMSService) debe consumir. Esto significa que hemos invertido el control, el (UIHandler) ya no es responsable de decidir qué implementación usar, el código de llamada lo hace. Hemos implementado el principio de inversión de control , que DI es un tipo de él.
El código del formulario de UI será el siguiente:
class Program
{
static void Main(string[] args)
{
ISMSService _SMSService = new MockSMSService(); // dependency
UIHandler _UIHandler = new UIHandler(_SMSService);
_UIHandler.SendConfirmationMsg("96279544480");
Console.ReadLine();
}
}
DI es un subconjunto de IoC
- IoC significa que los objetos no crean otros objetos en los que confían para hacer su trabajo. En su lugar, obtienen los objetos que necesitan de un servicio externo (por ejemplo, archivo xml o servicio de una sola aplicación). 2 implementaciones de IoC, que utilizo, son DI y ServiceLocator.
- DI significa que el principio de IoC de obtener un objeto dependiente se realiza sin usar objetos concretos sino abstracciones (interfaces). Esto hace que todos los componentes de la cadena sean verificables, ya que un componente de nivel superior no depende de un componente de nivel inferior, solo desde la interfaz. Mocks implementan estas interfaces.
En resumen, IoC es un término mucho más amplio que incluye, pero no se limita a, DI
El término Inversión de control (IoC) originalmente significaba cualquier tipo de estilo de programación donde un marco global o tiempo de ejecución controlaba el flujo del programa
Antes de que DI tuviera un nombre, las personas comenzaron a referirse a marcos que administran las Dependencias como Contenedores de Inversión de Control, y pronto, el significado de IoC se desvió gradualmente hacia ese significado particular: Inversión de Control sobre Dependencias.
Inversión de control (IoC) significa que los objetos no crean otros objetos en los que confían para hacer su trabajo. En su lugar, obtienen 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 la intervención del objeto, generalmente por un componente de marco que pasa parámetros de constructor y establece propiedades.
Encontré el mejor ejemplo en Dzone.com que es realmente útil para entender la diferencia real entre IOC y DI
“IoC es cuando alguien más crea objetos para usted”. Entonces, en lugar de escribir una palabra clave "nueva" (por ejemplo, MyCode c = new MyCode ()) en su código, el objeto lo crea alguien más. Este ''alguien más'' normalmente se conoce como un contenedor IoC. Significa que la entrega de rrsponsibility (control) al contenedor para obtener una instancia del objeto se llama Inversion of Control., Significa que en lugar de crear un objeto con un nuevo operador, deje que el contenedor haga 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.
IOC (Inversión de control) es básicamente un concepto de patrón de diseño para eliminar dependencias y desacoplarlas para que el flujo no sea lineal, y permitir que el contenedor u otra entidad gestione el aprovisionamiento de dependencias. En realidad, sigue al director de Hollywood: "No nos llames, te llamaremos". Así que resumimos las diferencias.
Inversión de control: - Es un término genérico para desacoplar las dependencias y delegar su aprovisionamiento, y esto puede implementarse de varias maneras (eventos, delegados, etc.).
Inyección de dependencia: - DI es un subtipo de IOC y se implementa mediante inyección de constructor, inyección de setter o inyección de método.
El siguiente artículo describe esto muy bien.
Inversion of Control es un principio de diseño genérico de la arquitectura de software que ayuda a crear marcos de software modulares y reutilizables que son fáciles de mantener.
Es un principio de diseño en el que el Flujo de control se "recibe" de la biblioteca escrita genérica o del código reutilizable.
Para entenderlo mejor, veamos cómo solíamos codificar en nuestros días anteriores de codificación. En los lenguajes de procedimiento / tradicionales, la lógica de negocios generalmente controla el flujo de la aplicación y "Llama" al código / funciones genérico o reutilizable. Por ejemplo, en una aplicación de consola simple, mi flujo de control está controlado por las instrucciones de mi programa, que pueden incluir llamadas a algunas funciones generales reutilizables.
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 IoC, los marcos son el código reutilizable que "Llama" a la lógica de negocios.
Por ejemplo, en un sistema basado en Windows, un marco ya estará disponible para crear elementos de la interfaz de usuario como botones, menús, ventanas y cuadros de diálogo. Cuando escribo la lógica de negocios de mi aplicación, serían los eventos del marco que llamarán a mi código de lógica de negocios (cuando se dispare un evento) y NO lo contrario.
Aunque el código del marco no es consciente de mi lógica de negocios, aún sabrá cómo llamar a mi código. Esto se logra mediante eventos / delegados, devoluciones de llamadas, etc. Aquí el control de flujo es "Invertido".
Por lo tanto, en lugar de depender del flujo de control de los objetos enlazados estáticamente, el flujo depende de la gráfica general del objeto y de las relaciones entre los diferentes objetos.
La inyección de dependencia es un patrón de diseño que implementa el principio de IoC para resolver dependencias de objetos.
En palabras más simples, cuando intenta escribir código, estará creando y usando diferentes clases. Una clase (Clase A) puede usar otras clases (Clase B y / o D). Entonces, las clases B y D son dependencias de la clase A.
Una simple analogía será una clase de coches. Un automóvil puede depender de otras clases como Motor, Neumáticos y más.
La inyección de dependencia sugiere que, en lugar de las clases dependientes (Class Car aquí) que crean sus dependencias (Class Engine y class Tire), la clase debe ser inyectada con la instancia concreta de la dependencia.
Vamos a entender con un ejemplo más práctico. Considera que estás escribiendo tu propio TextEditor. Entre otras cosas, puede tener un corrector ortográfico que le proporciona al usuario la posibilidad de verificar los errores tipográficos en su texto. Una implementación simple 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 se ve rosa. El usuario escribirá algún texto. El desarrollador capturará el texto y llamará a la función CheckSpellings y encontrará una lista de errores tipográficos que mostrará al usuario.
Todo parece funcionar bien hasta que un buen día, cuando un usuario comienza a escribir francés en el Editor.
Para proporcionar soporte para más idiomas, necesitamos tener más SpellCheckers. Probablemente francés, alemán, español, etc.
Aquí, hemos creado un código estrechamente acoplado con SpellChecker "Inglés" estrechamente acoplado con nuestra clase TextEditor, lo que significa que nuestra clase TextEditor depende del EnglishSpellChecker o, en otras palabras, EnglishSpellCheker es la dependencia de TextEditor. Necesitamos eliminar esta dependencia. Además, nuestro editor de texto necesita una forma de mantener la referencia concreta de cualquier corrector ortográfico en función de la discreción del desarrollador en el tiempo de ejecución.
Entonces, como vimos en la introducción de DI, sugiere que la clase debe ser inyectada con sus dependencias. Por lo tanto, debe ser responsabilidad del código de llamada inyectar todas las dependencias a la clase / código llamado. Así 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, la clase TextEditor debería recibir la instancia concreta del tipo ISpellChecker.
Ahora, la dependencia se puede inyectar en Constructor, una Propiedad pública o un método.
Tratemos de cambiar nuestra clase usando Constructor DI. La clase de TextEditor modificada tendrá un aspecto similar al siguiente:
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 crea el editor de texto, puede inyectar el tipo de corrector ortográfico adecuado en la instancia del editor de texto.
Puedes leer el artículo completo here
La inversión de control es un paradigma de diseño con el objetivo de otorgar más control a los componentes específicos de su aplicación, los que realizan el trabajo.
La inyección de dependencia es un patrón que se utiliza para crear instancias de objetos en los que se basan otros objetos sin saber en el momento de la compilación qué clase se utilizará para proporcionar esa funcionalidad.
Existen varias técnicas básicas para implementar la inversión de control. Estos son:
- Usando un patrón de fábrica
- Usando un patrón de localización de servicios
- Usando una inyección de dependencia de cualquier tipo dado a continuación:
1). Una inyección de constructor.
2). Una inyección de setter
3). Una inyección de interfaz
Pero la documentación de primavera dice que son iguales.
http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-introduction
En la primera línea " IoC también se conoce como inyección de dependencia (DI) ".
IoC (Iversión del control): - Es un término genérico e implementado de varias maneras (eventos, delegados, etc.).
DI ( D ependency I njection): - DI es un subtipo de IoC y se implementa mediante inyección de constructor, inyección de definidor o inyección de interfaz .
Pero, Spring soporta solo los siguientes dos tipos:
- Inyección de Setter
- La DI basada en Setter se realiza llamando a los métodos de establecimiento en los beans del usuario después de invocar un constructor sin argumentos o un método de fábrica estático sin argumentos para instanciar sus beans.
- Inyección Constructor
- El DI basado en el constructor se realiza invocando a un constructor con una serie de argumentos, cada uno representando un colaborador. Con esto podemos validar que los beans inyectados no son nulos y fallan rápido (tiempo de compilación), por lo que al iniciar la propia aplicación obtenemos la
NullPointerException: bean does not existLa inyección de constructor es la mejor práctica para inyectar dependencias.
- El DI basado en el constructor se realiza invocando a un constructor con una serie de argumentos, cada uno representando un colaborador. Con esto podemos validar que los beans inyectados no son nulos y fallan rápido (tiempo de compilación), por lo que al iniciar la propia aplicación obtenemos la
DI y IOC son dos patrones de diseño que se centran principalmente en proporcionar un acoplamiento suelto entre los componentes , o simplemente una forma en la que desacoplamos las relaciones de dependencia convencionales entre los objetos para que los objetos no estén apretados entre sí.
Con los siguientes ejemplos, estoy tratando de explicar estos dos conceptos.
Anteriormente estamos escribiendo 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, el inyector de dependencia 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 algún otro (por ejemplo, el contenedor) para la creación de instancias e inyección se puede denominar Inversión de control y el proceso en el que el contenedor IOC inyecta la dependencia para nosotros se puede denominar inyección de dependencia.
IOC es el principio donde el flujo de control de un programa se invierte: en lugar de que el programador controle el flujo de un programa , el programa controla el flujo al reducir la sobrecarga al programador. El proceso utilizado para inyectar la dependencia se denomina DI
Los dos conceptos trabajan juntos y nos proporcionan una manera de escribir código mucho más flexible, reutilizable y encapsulado, lo que los convierte en conceptos importantes en el diseño de soluciones orientadas a objetos.
También recomiendo leer.
¿Qué es la inyección de dependencia?
También puede consultar una de mis respuestas similares aquí
Diferencia entre inversión de control e inyección de dependencia
IOC (Inversion Of Controller): Dar control al contenedor para obtener una instancia del objeto se llama Inversion of Control. Significa que, en lugar de que usted esté creando un objeto con un nuevo operador , deje que el contenedor haga eso por usted.
DI (Inyección de dependencia): Pasar los parámetros (propiedades) requeridos de XML a un objeto (en CLASE POJO) se llama inyección de dependencia.
IOC (Inversion Of Controller) : Dar control al contenedor para obtener una instancia del objeto se llama Inversion of Control., Significa que en lugar de crear un objeto con el nuevo operador, deje que el contenedor haga eso por usted.
DI (inyección de dependencia) : la forma de inyectar 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
Spring solo admitirá Inyección Constructor y Inyección Setter / Getter.
IOC indica que una clase externa que administra las clases de una aplicación y las clases externas significa que un contenedor administra la dependencia entre la clase de aplicación. El concepto básico de IOC es que el programador no necesita crear sus objetos, sino describir cómo deben crearse.
Las tareas principales realizadas por el contenedor IoC son: crear una instancia de la clase de aplicación. para configurar el objeto. para ensamblar las dependencias entre los objetos.
DI es el proceso de proporcionar las dependencias de un objeto en tiempo de ejecución mediante el uso de inyección de colocador o inyección de constructor.
IoC : la inversión de control es un término genérico, independiente del lenguaje, en realidad no es crear los objetos, sino describir en qué modo se está creando el objeto.
DI - Inyección de dependencia es un término concreto, en el que proporcionamos dependencias del objeto en tiempo de ejecución mediante el uso de diferentes técnicas de inyección, a saber. Inyección de Setter, Inyección Constructor o por Inyección de Interfaz.
IoC es un término genérico que significa que, en lugar de que la aplicación llame a los métodos en un marco, el marco llama a las implementaciones proporcionadas por la aplicación.
DI es una forma de IoC, donde las implementaciones se pasan a un objeto a través de constructores / definidores / búsquedas de servicio, de las cuales el objeto "dependerá" para que se comporte correctamente.
IoC sin usar DI , por ejemplo, sería el patrón de plantilla porque la implementación solo se puede cambiar a través de la subclasificación.
Los marcos DI están diseñados para hacer uso de DI y pueden definir interfaces (o anotaciones en Java) para que sea más fácil pasar las implementaciones.
Los Contenedores IoC son marcos DI que pueden funcionar fuera del lenguaje de programación. En algunos, puede configurar qué implementaciones usar en los archivos de metadatos (por ejemplo, XML) que son menos invasivas. Con algunos puedes hacer IoC que normalmente sería imposible, como inyectar una implementación en pointcuts de pointcuts .
Vea también este artículo de Martin Fowler .