Sto facendo fatica a cercare risorse sul perché dovrei usare l' iniezione di dipendenza . La maggior parte delle risorse che vedo spiega che passa solo un'istanza di un oggetto a un'altra istanza di un oggetto, ma perché? Questo è solo per un'architettura / codice più pulito o influisce sulle prestazioni nel loro insieme?

Perché dovrei fare quanto segue?

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

Invece di quanto segue?

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

Il vantaggio è che senza iniezione di dipendenza, la tua classe di profilo

• deve sapere come creare un oggetto Impostazioni (viola il singolo principio di responsabilità)
• Crea sempre l'oggetto Impostazioni allo stesso modo (crea un accoppiamento stretto tra i due)

Ma con iniezione di dipendenza

• La logica per la creazione di oggetti Settings è altrove
• È facile usare diversi tipi di oggetti Impostazioni

Questo può sembrare (o addirittura essere) irrilevante in questo caso particolare, ma immagina se non stiamo parlando di un oggetto Settings, ma di un oggetto DataStore, che potrebbe avere implementazioni diverse, una che memorizza i dati in file e un'altra che li memorizza in un database. E per i test automatizzati anche tu vuoi un'implementazione fittizia. Ora non vuoi davvero che la classe Profile esegua il hardcode di quello che usa - e ancora più importante, davvero, davvero , non vuoi davvero che la classe Profile sia a conoscenza di percorsi di filesystem, connessioni DB e password, quindi la creazione di oggetti DataStore deve succedere altrove.

L'iniezione delle dipendenze semplifica il test del codice.

L'ho imparato di prima mano quando mi è stato assegnato il compito di correggere un bug difficile da catturare nell'integrazione di Magento con PayPal.

Un problema sorgeva quando PayPal informava Magento di un pagamento non riuscito: Magento non registrava correttamente l'errore.

Testare una potenziale correzione "manualmente" sarebbe molto noioso: dovresti in qualche modo attivare una notifica PayPal "non riuscita". Dovresti inviare un e-check, annullarlo e attendere che si verifichi un errore. Ciò significa 3+ giorni per testare una modifica del codice di un carattere!

Fortunatamente, sembra che gli sviluppatori principali di Magento che hanno sviluppato questa funzione abbiano in mente i test e abbiano usato un modello di iniezione di dipendenza per renderlo banale. Questo ci consente di verificare il nostro lavoro con un semplice test case come questo:

<?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());

Sono sicuro che il modello DI ha molti altri vantaggi, ma una maggiore testabilità è il più grande vantaggio nella mia mente .

Se sei curioso di sapere la soluzione a questo problema, dai un'occhiata al repository GitHub qui: https://github.com/bubbleupdev/BUCorefix_Paypalstatus

Perché (qual è anche il problema)?

Perché dovrei usare l'iniezione di dipendenza?

Il miglior mnemonico che ho trovato per questo è " new is glue ": ogni volta che lo usi newnel tuo codice, quel codice è legato a quella specifica implementazione . Se usi ripetutamente nuovi nei costruttori, creerai una catena di implementazioni specifiche . E poiché non puoi "avere" un'istanza di una classe senza costruirla, non puoi separare quella catena.

Ad esempio, immagina di scrivere un videogioco per auto da corsa. Hai iniziato con una classe Game, che crea a RaceTrack, che crea 8 Cars, che crea ciascuno a Motor. Ora, se vuoi altri 4 Carscon un'accelerazione diversa, dovrai cambiare ogni classe menzionata , tranne forse Game.

Codice più pulito

Questo è solo per un'architettura / codice più pulito

Sì .

Tuttavia, potrebbe benissimo sembrare meno chiaro in questa situazione, perché è più un esempio di come farlo . Il vantaggio effettivo mostra solo quando sono coinvolte più classi ed è più difficile da dimostrare, ma immagina che avresti usato DI nell'esempio precedente. Il codice che crea tutte queste cose potrebbe assomigliare a questo:

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);

È ora possibile aggiungere quelle 4 macchine diverse aggiungendo queste righe:

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);
}

• Nessun cambiamento in RaceTrack, Game, Car, o Motorsono stati necessari - il che significa che possiamo essere sicuri al 100% che non ci possono introdurre nuovi bug lì!
• Invece di dover saltare tra diversi file, sarai in grado di vedere la modifica completa sullo schermo allo stesso tempo. Questo è il risultato di vedere la creazione / installazione / configurazione come una propria responsabilità - non è compito di un'auto costruire un motore.

Considerazioni sulle prestazioni

o questo influenza le prestazioni nel loro insieme?

No . Ma per essere completamente onesto con te, potrebbe.

Tuttavia, anche in quel caso, è una quantità così ridicolmente piccola che non devi preoccuparti. Se ad un certo punto, in futuro, si deve scrivere codice per un tamagotchi con l'equivalente di 5 Mhz CPU e 2MB di RAM, allora forse si potrebbe avere a preoccuparsi di questo.

Nel 99,999% * dei casi avrà prestazioni migliori, perché hai impiegato meno tempo a correggere i bug e più tempo a migliorare i tuoi algoritmi ricchi di risorse.

* numero completamente inventato

Informazioni aggiunte: "hard-coded"

Non commettere errori, questo è ancora molto "hard-coded" - i numeri sono scritti direttamente nel codice. Non codificato significherebbe qualcosa come archiviare quei valori in un file di testo, ad esempio in formato JSON, e poi leggerli da quel file.

Per fare ciò, è necessario aggiungere codice per leggere un file e quindi analizzare JSON. Se consideri di nuovo l'esempio; nella versione non DI, a Caro a Motorora deve leggere un file. Non sembra che abbia troppo senso.

Nella versione DI, lo aggiungeresti al codice che imposta il gioco.

Sono sempre stato sconcertato dall'iniezione di dipendenza. Sembrava esistere solo all'interno delle sfere Java, ma quelle sfere ne parlavano con grande riverenza. È stato uno dei grandi Pattern, vedi, che si dice porti ordine nel caos. Ma gli esempi sono sempre stati contorti e artificiali, stabilendo un non-problema e poi iniziando a risolverlo rendendo il codice più complicato.

Aveva più senso quando un altro sviluppatore di Python mi ha impartito questa saggezza: sta solo passando argomenti alle funzioni. È a malapena un modello affatto; più come un promemoria che puoi chiedere qualcosa come argomento, anche se avresti potuto fornire te stesso un valore ragionevole.

Quindi la tua domanda è approssimativamente equivalente a "perché la mia funzione dovrebbe prendere argomenti?" e ha molte delle stesse risposte, vale a dire: lasciare che il chiamante prenda decisioni .

Questo ha un costo, ovviamente, perché ora stai forzando il chiamante a prendere una decisione (a meno che tu non renda l'argomento facoltativo) e l'interfaccia sia un po 'più complessa. In cambio, ottieni flessibilità.

Quindi: c'è una buona ragione per cui è necessario utilizzare questo particolare Settingtipo / valore? C'è una buona ragione per cui il codice chiamante potrebbe volere un Settingtipo / valore diverso ? (Ricorda, i test sono codice !)

L'esempio che dai non è l'iniezione di dipendenza in senso classico. L'iniezione di dipendenza di solito si riferisce al passaggio di oggetti in un costruttore o utilizzando "iniezione setter" subito dopo la creazione dell'oggetto, al fine di impostare un valore su un campo in un oggetto appena creato.

Il tuo esempio passa un oggetto come argomento a un metodo di istanza. Questo metodo di istanza quindi modifica un campo su quell'oggetto. Iniezione di dipendenza? No. Rompere l'incapsulamento e nascondere i dati? Assolutamente!

Ora, se il codice fosse così:

class Profile {
    private $settings;

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

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

Quindi direi che stai usando l'iniezione di dipendenza. La notevole differenza è che un Settingsoggetto viene passato al costruttore o a un Profileoggetto.

Ciò è utile se l'oggetto Settings è costoso o complesso da costruire, oppure Settings è un'interfaccia o una classe astratta in cui esistono più implementazioni concrete per modificare il comportamento in fase di esecuzione.

Poiché si accede direttamente a un campo sull'oggetto Impostazioni anziché chiamare un metodo, non è possibile sfruttare il polimorfismo, che è uno dei vantaggi dell'iniezione di dipendenza.

Sembra che le impostazioni per un profilo siano specifiche per quel profilo. In questo caso, farei una delle seguenti operazioni:

1. Crea un'istanza dell'oggetto Impostazioni all'interno del costruttore Profilo

2. Passa l'oggetto Impostazioni nel costruttore e copia sui singoli campi che si applicano al profilo

Onestamente, passando l'oggetto Impostazioni in deactivateProfilee quindi modificando un campo interno dell'oggetto Impostazioni è un odore di codice. L'oggetto Impostazioni dovrebbe essere l'unico che modifica i suoi campi interni.

So che arrivo tardi a questa festa, ma sento che manca un punto importante.

Perché dovrei farlo:

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

Non dovresti. Ma non perché l'iniezione di dipendenza è una cattiva idea. È perché sta sbagliando.

Vediamo queste cose usando il codice. Faremo questo:

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

quando ne ricaviamo la stessa cosa:

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

Quindi ovviamente sembra una perdita di tempo. È quando lo fai in questo modo. Questo non è il miglior uso dell'iniezione di dipendenza. Non è nemmeno il miglior uso di una classe.

E se invece avessimo questo:

$profile = new Profile($setting);

$application = new Application($profile);

$application.start();

E ora il applicationè libero di attivare e disattivare il profilesenza dover sapere nulla in particolare di settingciò che sta effettivamente cambiando. Perché va bene? Nel caso in cui sia necessario modificare le impostazioni. Ilapplication è murato fuori da tali modifiche in modo sei libero di andare noci in uno spazio contenuto sicuro senza dover guardare tutto rompere non appena si tocca qualcosa.

Ciò segue la costruzione separata dal comportamento principio di . Il modello DI qui è semplice. Costruisci tutto ciò di cui hai bisogno a un livello il più basso possibile, collegali insieme, quindi inizia tutto il ticchettio del comportamento con una chiamata.

Il risultato è che hai un posto separato per decidere cosa si collega a cosa e un posto diverso per gestire cosa dice cosa a qualunque cosa.

Provalo su qualcosa che devi mantenere nel tempo e vedi se non aiuta.

Come cliente, quando assumi un meccanico per fare qualcosa alla tua auto, ti aspetti che quel meccanico costruisca un'auto da zero solo per poi lavorare con essa? No, dai al meccanico l'auto su cui vuoi che lavori .

Come proprietario del garage, quando istruisci un meccanico a fare qualcosa a un'auto, ti aspetti che il meccanico crei le sue parti di cacciavite / chiave inglese / auto? No, fornisci al meccanico le parti / gli strumenti che deve usare

Perché lo facciamo? Ci pensiamo. Sei il proprietario di un garage che vuole assumere qualcuno per diventare il tuo meccanico. Insegnerai loro ad essere meccanici (= scriverai il codice).

Cosa sarà più facile:

• Insegna a un meccanico come collegare uno spoiler a un'auto usando un cacciavite.
• Insegnare a un meccanico a creare un'auto, creare uno spoiler, creare un cacciavite e quindi collegare lo spoiler appena creato all'auto appena creata con il cacciavite appena creato.

Ci sono enormi vantaggi nel non avere il tuo meccanico che crea tutto da zero:

• Ovviamente, l'addestramento (= sviluppo) si riduce drasticamente se fornisci al tuo meccanico strumenti e parti esistenti.
• Se lo stesso meccanico deve eseguire lo stesso lavoro più volte, puoi assicurarti che riutilizzi il cacciavite invece di buttare sempre quello vecchio e crearne uno nuovo.
• Inoltre, un meccanico che ha imparato a creare tutto dovrà essere molto più esperto, e quindi si aspetterà un salario più elevato. L'analogia con il codice qui è che una classe con molte responsabilità è molto più difficile da mantenere rispetto a una classe con una sola responsabilità strettamente definita.
• Inoltre, quando le nuove invenzioni colpiscono il mercato e gli spoiler vengono ora realizzati in carbonio anziché in plastica; dovrai riqualificarti (= riqualificare) il tuo meccanico esperto. Ma il tuo "semplice" meccanico non dovrà essere riqualificato fintanto che lo spoiler può ancora essere attaccato allo stesso modo.
• Avere un meccanico che non fa affidamento su un'auto che hanno costruito da soli significa che hai un meccanico che è in grado di gestire qualsiasi auto che possano ricevere. Comprese le auto che non esistevano ancora al momento dell'addestramento del meccanico. Tuttavia, il tuo meccanico esperto non sarà in grado di costruire auto più nuove che sono state create dopo l'allenamento.

Se assumi e addestra il meccanico esperto, finirai con un dipendente che costa di più, impiega più tempo a svolgere quello che dovrebbe essere un lavoro semplice e dovrà essere continuamente riqualificato ogni volta che uno dei tanti responsabilità ha bisogno per essere aggiornato.

L'analogia di sviluppo è che se usi le classi con dipendenze hardcoded, finirai con classi difficili da mantenere che avranno bisogno di continue riqualificazioni / modifiche ogni volta che Settingsviene creata una nuova versione dell'oggetto ( nel tuo caso), e tu dovrò sviluppare una logica interna affinché la classe abbia la capacità di creare diversi tipi di Settingsoggetti.

Inoltre, chiunque consuma la tua classe ora dovrà anche chiedere alla classe di creare l' Settingsoggetto corretto , invece di essere semplicemente in grado di passare alla classe qualsiasi Settingsoggetto che desideri passare. Ciò significa ulteriore sviluppo per il consumatore per capire come chiedere alla classe di creare lo strumento giusto.

Sì, l'inversione della dipendenza richiede un po 'più di sforzo per scrivere invece di codificare la dipendenza. Sì, è fastidioso dover scrivere di più.

Ma questo è lo stesso argomento della scelta di codificare i valori letterali perché "dichiarare le variabili richiede più sforzo". Tecnicamente corretto, ma i professionisti superano i contro di diversi ordini di grandezza .

Il vantaggio dell'inversione di dipendenza non si verifica quando si crea la prima versione dell'applicazione. Il vantaggio dell'inversione di dipendenza si verifica quando è necessario modificare o estendere quella versione iniziale. E non indurti a pensare che la prima volta lo otterrai correttamente e non dovrai estendere / modificare il codice. Dovrai cambiare le cose.

questo influenza le prestazioni nel loro insieme?

Ciò non influisce sulle prestazioni di runtime dell'applicazione. Ma ha un impatto enorme sui tempi di sviluppo (e quindi sulle prestazioni) dello sviluppatore .

Come tutti i motivi, è molto valido chiedere "perché" per evitare disegni gonfiati.

Per l'iniezione di dipendenza, questo è facilmente visibile pensando ai due, probabilmente, aspetti più importanti del design OOP ...

Accoppiamento basso

Accoppiamento nella programmazione informatica :

Nell'ingegneria del software, l'accoppiamento è il grado di interdipendenza tra i moduli software; una misura di quanto siano strettamente collegate due routine o moduli; la forza delle relazioni tra i moduli.

Vuoi ottenere basso accoppiamento . Due cose che sono fortemente accoppiate significano che se cambi l'una, molto probabilmente dovrai cambiare l'altra. Bug o restrizioni nell'uno probabilmente indurranno bug / restrizioni nell'altro; e così via.

Una classe che crea istanze di oggetti degli altri è un accoppiamento molto forte, perché l'uno deve sapere dell'esistenza dell'altro; deve sapere come istanziarlo (di quali argomenti ha bisogno il costruttore) e tali argomenti devono essere disponibili quando si chiama il costruttore. Inoltre, a seconda che il linguaggio necessiti di decostruzione esplicita (C ++), ciò introdurrà ulteriori complicazioni. Se si introducono nuove classi (ad es. ANextSettings o altro), è necessario tornare alla classe originale e aggiungere più chiamate ai loro costruttori.

Alta coesione

Coesione :

Nella programmazione per computer, la coesione si riferisce al grado in cui gli elementi all'interno di un modulo appartengono insieme.

Questo è l'altro lato della medaglia. Se osservi un'unità di codice (un metodo, una classe, un pacchetto ecc.), Vuoi che tutto il codice all'interno di quell'unità abbia il minor numero di responsabilità possibile.

Un esempio di base per questo sarebbe il modello MVC: separi chiaramente il modello di dominio dalla vista (GUI) e un livello di controllo che li incolla.

Questo evita che il codice si gonfi quando ottieni grossi pezzi che fanno molte cose diverse; se si desidera modificarne una parte, è necessario tenere traccia anche di tutte le altre funzionalità, cercando di evitare bug, ecc .; e ti programmi rapidamente in un buco in cui è molto difficile uscire.

Con l'iniezione delle dipendenze, deleghi la creazione o tenendo traccia delle dipendenze, indipendentemente dalle classi (o dai file di configurazione) che implementano il tuo DI. Le altre classi non si preoccuperanno molto di quello che sta succedendo esattamente - lavoreranno con alcune interfacce generiche e non hanno idea di quale sia l'implementazione effettiva, il che significa che non sono responsabili delle altre cose.

Dovresti usare tecniche per risolvere i problemi che sono bravi a risolvere quando hai quei problemi. L'inversione e l'iniezione delle dipendenze non sono diverse.

L'inversione o iniezione di dipendenza è una tecnica che consente al codice di decidere quale implementazione di un metodo viene chiamata in fase di esecuzione. Ciò massimizza i benefici dell'associazione tardiva. La tecnica è necessaria quando la lingua non supporta la sostituzione in fase di esecuzione di funzioni non di istanza. Ad esempio, Java non ha un meccanismo per sostituire le chiamate a un metodo statico con chiamate a un'implementazione diversa; contrasto con Python, dove tutto ciò che è necessario per sostituire la chiamata di funzione è associare il nome a un'altra funzione (riassegnare la variabile che contiene la funzione).

Perché dovremmo voler variare l'implementazione della funzione? Vi sono due ragioni principali:

• Vogliamo usare i falsi a scopo di test. Questo ci consente di testare una classe che dipende da un recupero del database senza effettivamente collegarsi al database.
• Dobbiamo supportare più implementazioni. Ad esempio, potrebbe essere necessario configurare un sistema che supporti sia i database MySQL sia PostgreSQL.

È inoltre possibile prendere nota dell'inversione dei contenitori di controllo. Questa è una tecnica che ti aiuterà a evitare enormi alberi da costruzione aggrovigliati che assomigliano a questo pseudocodice:

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)
);

Ti consente di registrare le tue lezioni e quindi fa la costruzione per te:

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.

Si noti che è più semplice se le classi registrate possono essere singoli senza stato .

Avvertenza

Si noti che l'inversione di dipendenza non dovrebbe essere la risposta ideale per la logica di disaccoppiamento. Cerca invece opportunità per usare la parametrizzazione . Considera questo metodo pseudocodice per esempio:

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;
}

Potremmo usare l'inversione di dipendenza per alcune parti di questo metodo:

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;
    }

Ma non dovremmo, almeno non del tutto. Si noti che abbiamo creato una classe stateful con Querier. Ora contiene un riferimento ad alcuni oggetti di connessione essenzialmente globali. Ciò crea problemi come difficoltà a comprendere lo stato generale del programma e il modo in cui le diverse classi si coordinano tra loro. Si noti inoltre che siamo costretti a falsificare la query o la connessione se vogliamo testare la logica della media. Ulteriori Un approccio migliore sarebbe quello di aumentare la parametrizzazione :

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);
    }
}

E la connessione verrebbe gestita ad un livello ancora più alto che è responsabile dell'intera operazione e sa cosa fare con questo output.

Ora possiamo testare la logica della media in modo completamente indipendente dalla query e, inoltre, possiamo usarla in una più ampia varietà di situazioni. Potremmo chiederci se abbiamo persino bisogno degli oggetti MyQueriere Averager, e forse la risposta è che non lo facciamo se non intendiamo test unitari StuffDoer, e non i test unitari StuffDoersarebbero perfettamente ragionevoli dal momento che sono così strettamente accoppiati al database. Potrebbe avere più senso lasciare che i test di integrazione lo coprano. In tal caso, potremmo andare bene fare fetchAboveMine averageDatain metodi statici.