Me resulta difícil buscar recursos sobre por qué debería usar la inyección de dependencia . La mayoría de los recursos que veo explican que simplemente pasa una instancia de un objeto a otra instancia de un objeto, pero ¿por qué? ¿Es esto solo para una arquitectura / código más limpio o esto afecta el rendimiento en general?

¿Por qué debería hacer lo siguiente?

class Profile {
    public function deactivateProfile(Setting $setting)
    {
        $setting->isActive = false;
    }
}

En lugar de lo siguiente?

class Profile {
    public function deactivateProfile()
    {
        $setting = new Setting();
        $setting->isActive = false;
    }
}

La ventaja es que sin inyección de dependencia, su clase de perfil

• necesita saber cómo crear un objeto de Configuración (viola el Principio de responsabilidad única)
• Siempre crea su objeto Configuración de la misma manera (crea un acoplamiento estrecho entre los dos)

Pero con inyección de dependencia

• La lógica para crear objetos de configuración está en otro lugar
• Es fácil usar diferentes tipos de objetos de configuración

Esto puede parecer (o incluso ser) irrelevante en este caso en particular, pero imagine que no estamos hablando de un objeto de Configuración, sino de un objeto DataStore, que podría tener implementaciones diferentes, una que almacena datos en archivos y otra que los almacena en una base de datos Y para las pruebas automatizadas, también desea una implementación simulada. Ahora realmente no desea que la clase Profile codifique cuál usa, y lo que es más importante, realmente no desea que la clase Profile conozca las rutas del sistema de archivos, las conexiones DB y las contraseñas, por lo que la creación de objetos DataStore tiene que suceder en otro lugar.

La inyección de dependencia hace que su código sea más fácil de probar.

Aprendí esto de primera mano cuando me encargaron corregir un error difícil de detectar en la integración de PayPal de Magento.

Surgiría un problema cuando PayPal le informara a Magento sobre un pago fallido: Magento no registraría el error correctamente.

Probar una posible solución "manualmente" sería muy tedioso: tendría que activar de alguna manera una notificación de PayPal "Fallida". Tendría que enviar un cheque electrónico, cancelarlo y esperar a que se produzca un error. ¡Eso significa más de 3 días para probar un cambio de código de un carácter!

Afortunadamente, parece que los desarrolladores principales de Magento que desarrollaron esta función tenían en mente las pruebas y usaron un patrón de inyección de dependencia para hacerlo trivial. Esto nos permite verificar nuestro trabajo con un caso de prueba simple como este:

<?php
// This is the dependency we will inject to facilitate our testing
class MockHttpClient extends Varien_Http_Adapter_Curl {
    function read() {
        // Make Magento think that PayPal said "VERIFIED", no matter what they actually said...
        return "HTTP/1.1 200 OK\n\nVERIFIED";
    }
}

// Here, we trick Magento into thinking PayPal actually sent something back.
// Magento will try to verify it against PayPal's API though, and since it's fake data, it'll always fail.
$ipnPayload = array (
  'invoice'        => '100058137',         // Order ID to test against
  'txn_id'         => '04S87540L2309371A', // Test PayPal transaction ID
  'payment_status' => 'Failed'             // New payment status that Magento should ingest
);

// This is what Magento's controller calls during a normal IPN request.
// Instead of letting Magento talk to PayPal, we "inject" our fake HTTP client, which always returns VERIFIED.
Mage::getModel('paypal/ipn')->processIpnRequest($ipnPayload, new MockHttpClient());

Estoy seguro de que el patrón DI tiene muchas otras ventajas, pero una mayor capacidad de prueba es el mayor beneficio en mi mente .

Si tiene curiosidad sobre la solución a este problema, consulte el repositorio de GitHub aquí: https://github.com/bubbleupdev/BUCorefix_Paypalstatus

¿Por qué (cuál es el problema)?

¿Por qué debería usar la inyección de dependencia?

El mejor mnemónico que encontré para esto es " nuevo es pegamento ": cada vez que lo usa newen su código, ese código está vinculado a esa implementación específica . Si usa repetidamente new en constructores, creará una cadena de implementaciones específicas . Y debido a que no puede "tener" una instancia de una clase sin construirla, no puede separar esa cadena.

Como ejemplo, imagina que estás escribiendo un videojuego de autos de carrera. Comenzaste con una clase Game, que crea un RaceTrack, que crea 8 Cars, que cada uno crea un Motor. Ahora, si quieres 4 adicionales Carscon una aceleración diferente, tendrás que cambiar cada clase mencionada , excepto tal vez Game.

Código más limpio

¿Es esto solo para una arquitectura / código más limpio?

Sí .

Sin embargo, podría parecer menos claro en esta situación, porque es más un ejemplo de cómo hacerlo . La ventaja real solo se muestra cuando hay varias clases involucradas y es más difícil de demostrar, pero imagina que hubieras usado DI en el ejemplo anterior. El código que crea todas esas cosas podría verse así:

List<Car> cars = new List<Car>();
for(int i=0; i<8; i++){
    float acceleration = 0.3f;
    float maxSpeed = 200.0f;
    Motor motor = new Motor(acceleration, maxSpeed);
    Car car = new Car(motor);
    cars.Add(car);
}
RaceTrack raceTrack = new RaceTrack(cars);
Game game = new Game(raceTrack);

Ahora puede agregar esos 4 autos diferentes agregando estas líneas:

for(int i=0; i<4; i++){
    float acceleration = 0.5f;
    float maxSpeed = 100.0f;
    Motor motor = new Motor(acceleration, maxSpeed);
    Car car = new Car(motor);
    cars.Add(car);
}

• No hay cambios en RaceTrack, Game, Car, o Motoreran necesarios - lo que significa que podemos estar 100% seguros de que no ha introducido ningún otro bichos allí!
• En lugar de tener que saltar entre varios archivos, podrá ver el cambio completo en su pantalla al mismo tiempo. Esto es el resultado de ver la creación / instalación / configuración como una responsabilidad propia : no es el trabajo de un automóvil construir un motor.

Consideraciones de rendimiento

o esto afecta el rendimiento en su conjunto?

No se . Pero para ser completamente honesto contigo, podría ser.

Sin embargo, incluso en ese caso, es una cantidad tan ridículamente pequeña que no necesita preocuparse. Si en algún momento en el futuro, usted tiene que escribir código para un tamagotchi con el equivalente de 5Mhz CPU y 2 MB de RAM, entonces tal vez usted puede ser que tenga que preocuparse por esto.

En el 99.999% * de los casos, tendrá un mejor rendimiento, ya que pasó menos tiempo reparando errores y más tiempo mejorando sus algoritmos con muchos recursos.

* número completamente inventado

Información adicional: "codificado"

No se equivoque, esto todavía está muy "codificado": los números se escriben directamente en el código. No codificado significaría algo así como almacenar esos valores en un archivo de texto, por ejemplo, en formato JSON, y luego leerlos desde ese archivo.

Para hacerlo, debe agregar código para leer un archivo y luego analizar JSON. Si considera el ejemplo nuevamente; en la versión no DI, a Caro a Motorahora tiene que leer un archivo. Eso no parece que tenga demasiado sentido.

En la versión DI, lo agregaría al código que configura el juego.

Siempre me desconcertó la inyección de dependencia. Parecía existir solo dentro de las esferas de Java, pero esas esferas hablaron de ello con gran reverencia. Fue uno de los grandes patrones, ya ves, que se dice que da orden al caos. Pero los ejemplos siempre fueron complicados y artificiales, estableciendo un problema y luego resolviéndolo haciendo el código más complicado.

Tenía más sentido cuando un compañero desarrollador de Python me impartió esta sabiduría: es solo pasar argumentos a las funciones. Es apenas un patrón en absoluto; más como un recordatorio de que usted puede pedir algo como un argumento, incluso si usted podría haber proporcionado concebible un valor razonable a sí mismo.

Entonces, su pregunta es más o menos equivalente a "¿por qué mi función debe tomar argumentos?" y tiene muchas de las mismas respuestas, a saber: dejar que la persona que llama tome decisiones .

Esto tiene un costo, por supuesto, porque ahora está obligando a la persona que llama a tomar alguna decisión (a menos que haga que el argumento sea opcional), y la interfaz es algo más compleja. A cambio, ganas flexibilidad.

Entonces: ¿Hay una buena razón por la que específicamente necesita usar este Settingtipo / valor en particular ? ¿Hay una buena razón por la cual el código de llamada podría querer un Settingtipo / valor diferente ? (¡Recuerde, las pruebas son código !)

El ejemplo que da no es la inyección de dependencia en el sentido clásico. La inyección de dependencia generalmente se refiere a pasar objetos en un constructor o mediante el uso de "inyección de setter" justo después de crear el objeto, para establecer un valor en un campo en un objeto recién creado.

Su ejemplo pasa un objeto como argumento a un método de instancia. Este método de instancia modifica un campo en ese objeto. ¿Inyección de dependencia? No. ¿Romper encapsulación y ocultar datos? ¡Absolutamente!

Ahora, si el código fuera así:

class Profile {
    private $settings;

    public function __construct(Settings $settings) {
        $this->settings = $settings;
    }

    public function deactive() {
        $this->settings->isActive = false;
    }
}

Entonces diría que está utilizando inyección de dependencia. La diferencia notable es que un Settingsobjeto se pasa al constructor o un Profileobjeto.

Esto es útil si el objeto Configuración es costoso o complejo de construir, o Configuración es una interfaz o clase abstracta donde existen múltiples implementaciones concretas para cambiar el comportamiento del tiempo de ejecución.

Dado que está accediendo directamente a un campo en el objeto Configuración en lugar de llamar a un método, no puede aprovechar el Polimorfismo, que es uno de los beneficios de la inyección de dependencia.

Parece que la configuración de un perfil es específica de ese perfil. En este caso, haría uno de los siguientes:

1. Instanciar el objeto de configuración dentro del constructor de perfiles

2. Pase el objeto Configuración en el constructor y copie sobre campos individuales que se aplican al Perfil

Honestamente, al pasar el objeto Configuración a deactivateProfiley luego modificar un campo interno del objeto Configuración es un olor a código. El objeto Configuración debería ser el único que modifique sus campos internos.

Sé que voy a llegar tarde a esta fiesta, pero siento que se está perdiendo un punto importante.

Por qué debería hacer esto:

class Profile {
    public function deactivateProfile(Setting $setting)
    {
        $setting->isActive = false;
    }
}

No deberías Pero no porque la inyección de dependencia sea una mala idea. Es porque esto lo está haciendo mal.

Veamos estas cosas usando código. Vamos a hacer esto:

$profile = new Profile();
$profile->deactivateProfile($setting);

cuando obtenemos lo mismo de esto:

$setting->isActive = false; // Deactivate profile

Entonces, por supuesto, parece una pérdida de tiempo. Es cuando lo haces de esta manera. Este no es el mejor uso de la inyección de dependencia. Ni siquiera es el mejor uso de una clase.

Ahora, ¿y si en cambio tuviéramos esto?

$profile = new Profile($setting);

$application = new Application($profile);

$application.start();

Y ahora applicationes libre de activar y desactivar profilesin tener que saber nada en particular acerca de lo settingque realmente está cambiando. ¿Por qué es eso bueno? En caso de que necesite cambiar la configuración. El applicationestá amurallado fuera de esos cambios por lo que es libre de ir tuercas en un espacio contenido seguro sin tener que mirar todo romper tan pronto como se toca algo.

Esto sigue la construcción separada del principio de comportamiento . El patrón DI aquí es simple. Construya todo lo que necesite al nivel más bajo posible, conéctelos y luego comience a marcar todo el comportamiento con una sola llamada.

El resultado es que tiene un lugar separado para decidir qué se conecta con qué y un lugar diferente para administrar lo que dice qué a lo que sea.

Intente eso en algo que tiene que mantener con el tiempo y vea si no ayuda.

Como cliente, cuando contrata a un mecánico para que le haga algo a su automóvil, ¿espera que ese mecánico construya un automóvil desde cero solo para luego trabajar con él? No, le das al mecánico el auto en el que quieres que trabajen .

Como propietario del garaje, cuando le indica a un mecánico que le haga algo a un automóvil, ¿espera que el mecánico cree sus propias piezas de destornillador / llave / automóvil? No, usted le proporciona al mecánico las piezas / herramientas que necesita usar

¿Por qué hacemos esto? Bueno, piensalo. Eres propietario de un garaje que quiere contratar a alguien para que se convierta en tu mecánico. Les enseñarás a ser mecánicos (= escribirás el código).

¿Qué va a ser más fácil?

• Enseñe a un mecánico cómo conectar un alerón a un automóvil con un destornillador.
• Enseñe a un mecánico a crear un automóvil, crear un spoiler, crear un destornillador y luego conectar el spoiler recién creado al automóvil recién creado con el destornillador recién creado.

Hay enormes beneficios de no hacer que tu mecánico cree todo desde cero:

• Obviamente, la capacitación (= desarrollo) se acorta drásticamente si solo le proporciona a su mecánico las herramientas y piezas existentes.
• Si el mismo mecánico tiene que realizar el mismo trabajo varias veces, puede asegurarse de que vuelva a usar el destornillador en lugar de tirar siempre el viejo y crear uno nuevo.
• Además, un mecánico que ha aprendido a crear todo necesitará ser mucho más experto y, por lo tanto, esperará un salario más alto. La analogía de codificación aquí es que una clase con muchas responsabilidades es mucho más difícil de mantener que una clase con una sola responsabilidad estrictamente definida.
• Además, cuando los nuevos inventos llegan al mercado y los spoilers ahora se fabrican con carbono en lugar de plástico; Tendrá que volver a entrenar (= volver a desarrollar) su mecánico experto. Pero su mecánico "simple" no tendrá que volverse a entrenar siempre y cuando el spoiler todavía se pueda conectar de la misma manera.
• Tener un mecánico que no confía en un automóvil que ellos mismos han construido significa que usted tiene un mecánico que puede manejar cualquier automóvil que pueda recibir. Incluyendo autos que ni siquiera existían al momento de entrenar al mecánico. Sin embargo, su mecánico experto no podrá construir autos más nuevos que hayan sido creados después de su entrenamiento.

Si contrata y entrena el experto mecánico, que va a terminar con un empleado que cuesta más, toma más tiempo para llevar a cabo lo que debe ser un trabajo sencillo, y necesitará ser perpetuamente nueva formación cada vez que una de sus muchas responsabilidades necesitan Para actualizarse.

La analogía del desarrollo es que si usa clases con dependencias codificadas, entonces terminará con clases difíciles de mantener que necesitarán una reurbanización / cambios continuos cada vez que Settingsse cree una nueva versión del objeto ( en su caso), y usted Tendrá que desarrollar una lógica interna para que la clase tenga la capacidad de crear diferentes tipos de Settingsobjetos.

Además, quien consuma su clase ahora también tendrá que pedirle a la clase que cree el Settingsobjeto correcto , en lugar de simplemente poder pasarle a la clase cualquier Settingsobjeto que desee pasar. Esto significa un desarrollo adicional para que el consumidor descubra cómo pedirle a la clase que cree la herramienta adecuada.

Sí, la inversión de dependencia requiere un poco más de esfuerzo para escribir en lugar de codificar la dependencia. Sí, es molesto tener que escribir más.

Pero ese es el mismo argumento que elegir codificar valores literales porque "declarar variables requiere más esfuerzo". Técnicamente correcto, pero los profesionales superan a los contras en varios órdenes de magnitud .

El beneficio de la inversión de dependencia no se experimenta cuando crea la primera versión de la aplicación. El beneficio de la inversión de dependencia se experimenta cuando necesita cambiar o ampliar esa versión inicial. Y no se engañe pensando que lo hará bien la primera vez y que no necesitará extender / cambiar el código. Tendrás que cambiar las cosas.

¿Esto afecta el rendimiento en su conjunto?

Esto no afecta el rendimiento en tiempo de ejecución de la aplicación. Pero impacta masivamente el tiempo de desarrollo (y por lo tanto el rendimiento) del desarrollador .

Como todos los patrones, es muy válido preguntar "por qué" para evitar diseños hinchados.

Para la inyección de dependencia, esto se ve fácilmente al pensar en las dos, posiblemente, las facetas más importantes del diseño OOP ...

Bajo acoplamiento

Acoplamiento en programación de computadoras :

En ingeniería de software, el acoplamiento es el grado de interdependencia entre los módulos de software; una medida de cuán estrechamente conectados están dos rutinas o módulos; La fuerza de las relaciones entre los módulos.

Desea lograr un bajo acoplamiento. El hecho de que dos cosas estén fuertemente acopladas significa que si cambia una, es muy probable que tenga que cambiar la otra. Los errores o restricciones en uno probablemente inducirán errores / restricciones en el otro; y así.

Una clase de objetos de instancia de los otros es un acoplamiento muy fuerte, porque uno necesita saber acerca de la existencia del otro; necesita saber cómo instanciarlo (qué argumentos necesita el constructor), y esos argumentos deben estar disponibles al llamar al constructor. Además, dependiendo de si el lenguaje necesita deconstrucción explícita (C ++), esto introducirá más complicaciones. Si introduce nuevas clases (es decir, a NextSettingso lo que sea), debe volver a la clase original y agregar más llamadas a sus constructores.

Alta cohesión

Cohesión :

En la programación de computadoras, la cohesión se refiere al grado en que los elementos dentro de un módulo pertenecen juntos.

Esta es la otra cara de la moneda. Si observa una unidad de código (un método, una clase, un paquete, etc.), desea tener todo el código dentro de esa unidad para tener la menor cantidad de responsabilidades posible.

Un ejemplo básico para esto sería el patrón MVC: separa claramente el modelo de dominio de la vista (GUI) y una capa de control que los une.

Esto evita la hinchazón de código donde se obtienen grandes fragmentos que hacen muchas cosas diferentes; si desea cambiar alguna parte, también debe realizar un seguimiento de todas las demás funciones, tratando de evitar errores, etc .; y rápidamente te programas en un agujero donde es muy difícil salir.

Con la inyección de dependencias, delega la creación o el seguimiento de, bueno, dependencias a cualquier clase (o archivo de configuración) que implemente su DI. A otras clases no les importará mucho lo que está sucediendo exactamente: trabajarán con algunas interfaces genéricas y no tienen idea de cuál es la implementación real, lo que significa que no son responsables de las otras cosas.

Debes usar técnicas para resolver los problemas que son buenos para resolver cuando tienes esos problemas. La inversión de dependencia y la inyección no son diferentes.

La inversión o inyección de dependencia es una técnica que le permite a su código decidir qué implementación de un método se llama en tiempo de ejecución. Esto maximiza los beneficios de la unión tardía. La técnica es necesaria cuando el lenguaje no admite el reemplazo en tiempo de ejecución de funciones que no son de instancia. Por ejemplo, Java carece de un mecanismo para reemplazar las llamadas a un método estático con llamadas a una implementación diferente; contraste con Python, donde todo lo que es necesario para reemplazar la llamada a la función es vincular el nombre a una función diferente (reasignar la variable que contiene la función).

¿Por qué querríamos variar la implementación de la función? Hay dos razones principales:

• Queremos usar falsificaciones con fines de prueba. Esto nos permite probar una clase que depende de una búsqueda de la base de datos sin conectarse realmente a la base de datos.
• Necesitamos soportar múltiples implementaciones. Por ejemplo, podríamos necesitar configurar un sistema que sea compatible con las bases de datos MySQL y PostgreSQL.

También puede tomar nota de la inversión de los contenedores de control. Esta es una técnica destinada a ayudarlo a evitar árboles de construcción enormes y enredados que se parecen a este pseudocódigo:

thing5 =  new MyThing5();
thing3 = new MyThing3(thing5, new MyThing10());

myApp = new MyApp(
    new MyAppDependency1(thing5, thing3),
    new MyAppDependency2(
        new Thing1(),
        new Thing2(new Thing3(thing5, new Thing4(thing5)))
    ),
    ...
    new MyAppDependency15(thing5)
);

Te permite registrar tus clases y luego hace la construcción por ti:

injector.register(Thing1); // Yes, you'd need some kind of actual class reference.
injector.register(Thing2);
...
injector.register(MyAppDepdency15);
injector.register(MyApp);

myApp = injector.create(MyApp); // The injector fills in all the construction parameters.

Tenga en cuenta que es más simple si las clases registradas pueden ser singletons sin estado .

Palabra de precaución

Tenga en cuenta que la inversión de dependencia no debería ser su respuesta a la lógica de desacoplamiento. Busque oportunidades para utilizar la parametrización en su lugar. Considere este método de pseudocódigo, por ejemplo:

myAverageAboveMin()
{
    dbConn = new DbConnection("my connection string");
    dbQuery = dbConn.makeQuery();
    dbQuery.Command = "SELECT * FROM MY_DATA WHERE x > :min";
    dbQuery.setParam("min", 5);
    dbQuery.Execute();
    myData = dbQuery.getAll();
    count = 0;
    total = 0;
    foreach (row in myData)
    {
        count++;
        total += row.x;
    }

    return total / count;
}

Podríamos usar la inversión de dependencia para algunas partes de este método:

class MyQuerier
{
    private _dbConn;

    MyQueries(dbConn) { this._dbConn = dbConn; }

    fetchAboveMin(min)
    {
        dbQuery = this._dbConn.makeQuery();
        dbQuery.Command = "SELECT * FROM MY_DATA WHERE x > :min";
        dbQuery.setParam("min", min);
        dbQuery.Execute();
        return dbQuery.getAll();
    }
}


class Averager
{
    private _querier;

    Averager(querier) { this._querier = querier; }

    myAverageAboveMin(min)
    {
        myData = this._querier.fetchAboveMin(min);
        count = 0;
        total = 0;
        foreach (row in myData)
        {
            count++;
            total += row.x;
        }

        return total / count;
    }

Pero no deberíamos, al menos no completamente. Tenga en cuenta que hemos creado una clase con estado con Querier. Ahora contiene una referencia a algún objeto de conexión esencialmente global. Esto crea problemas como la dificultad para comprender el estado general del programa y cómo las diferentes clases se coordinan entre sí. Tenga en cuenta también que estamos obligados a falsificar el interrogador o la conexión si queremos probar la lógica de promedio. Además, un mejor enfoque sería aumentar la parametrización :

class MyQuerier
{
    fetchAboveMin(dbConn, min)
    {
        dbQuery = dbConn.makeQuery();
        dbQuery.Command = "SELECT * FROM MY_DATA WHERE x > :min";
        dbQuery.setParam("min", min);
        dbQuery.Execute();
        return dbQuery.getAll();
    }
}


class Averager
{
    averageData(myData)
    {
        count = 0;
        total = 0;
        foreach (row in myData)
        {
            count++;
            total += row.x;
        }

        return total / count;
    }

class StuffDoer
{
    private _querier;
    private _averager;

    StuffDoer(querier, averager)
    {
        this._querier = querier;
        this._averager = averager;
    }

    myAverageAboveMin(dbConn, min)
    {
        myData = this._querier.fetchAboveMin(dbConn, min);
        return this._averager.averageData(myData);
    }
}

Y la conexión se administraría a un nivel aún mayor que es responsable de la operación en su conjunto y sabe qué hacer con esta salida.

Ahora podemos probar la lógica de promedios completamente independiente de la consulta, y además, podemos usarla en una variedad más amplia de situaciones. Podríamos preguntarnos si incluso necesitamos los objetos MyQueriery Averager, y tal vez la respuesta es que no lo hacemos si no pretendemos realizar una prueba unitaria StuffDoer, y no la prueba unitaria StuffDoersería perfectamente razonable ya que está tan estrechamente acoplada a la base de datos. Puede tener más sentido dejar que las pruebas de integración lo cubran. En ese caso, podría estar haciendo bien fetchAboveMiny averageDataen los métodos estáticos.