La inversión de 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 genérica escrita o del código reutilizable.
Para entenderlo mejor, veamos cómo solíamos codificar en nuestros primeros días de codificación. En los lenguajes procedimentales / tradicionales, la lógica empresarial generalmente controla el flujo de la aplicación y "llama" al código / funciones genéricos o reutilizables. Por ejemplo, en una aplicación de consola simple, mi flujo de control está controlado por las instrucciones de mi programa, que pueden incluir las 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 Frameworks son el código reutilizable que "llama" a la lógica empresarial.
Por ejemplo, en un sistema basado en Windows, ya estará disponible un marco para crear elementos de la interfaz de usuario como botones, menús, ventanas y cuadros de diálogo. Cuando escribo la lógica empresarial de mi aplicación, serían los eventos del framework los que llamarían a mi código de lógica empresarial (cuando se activa un evento) y NO al contrario.
Aunque el código del marco no conoce mi lógica empresarial, aún sabrá cómo llamar a mi código. Esto se logra mediante eventos / delegados, devoluciones de llamada, etc. Aquí el control de flujo está "Invertido".
Entonces, en lugar de depender del flujo de control en objetos vinculados estáticamente, el flujo depende del gráfico de objeto general y las relaciones entre 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 intente escribir código, creará y usará diferentes clases. Una clase (Clase A) puede utilizar otras clases (Clase B y / o D). Entonces, las clases B y D son dependencias de la clase A.
Una simple analogía sería un auto de clase. 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 que las clases dependientes (Class Car aquí) creen sus dependencias (Class Engine y class Tire), la clase debería inyectarse con la instancia concreta de la dependencia.
Entendamos con un ejemplo más práctico. Considere que está escribiendo su propio TextEditor. Entre otras cosas, puede tener un corrector ortográfico que le proporcione 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 parece color de 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 le mostrará al usuario.
Todo parece funcionar muy bien hasta que un buen día un usuario comienza a escribir en francés en el Editor.
Para proporcionar soporte para más idiomas, necesitamos tener más correctores ortográficos. Probablemente francés, alemán, español, etc.
Aquí, hemos creado un código estrechamente acoplado con "English" SpellChecker estrechamente acoplado con nuestra clase TextEditor, lo que significa que nuestra clase TextEditor depende de 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 contener la referencia concreta de cualquier corrector ortográfico según el criterio del desarrollador en tiempo de ejecución.
Entonces, como vimos en la introducción de DI, sugiere que la clase debe inyectarse con sus dependencias. Por lo tanto, debería ser responsabilidad del código de llamada inyectar todas las dependencias a la clase / código llamado. Entonces 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.
Intentemos cambiar nuestra clase usando Constructor DI. La clase TextEditor modificada se verá así:
Class TextEditor
{
ISpellChecker objSpellChecker;
string Text;
public void TextEditor(ISpellChecker objSC)
{
objSpellChecker = objSC;
}
public ArrayList <typos> CheckSpellings()
{
return objSpellChecker.CheckSpelling();
}
}
Para que el código de llamada, mientras crea el editor de texto, pueda inyectar el tipo de corrector ortográfico apropiado en la instancia del TextEditor.
Puedes leer el artículo completo aquí