Dagger 2 per sviluppatori Android inesperti. Iniezione di dipendenza. Parte 1

Questo articolo è la seconda parte di una serie di articoli destinati, secondo l'autore, a coloro che non possono comprendere l' iniezione di dipendenza e il framework Dagger 2 , o semplicemente lo faranno. Originale scritto il 25 novembre 2017. Le immagini e le GIF provengono dall'originale. Traduzione gratis.
Immagine

Questo è il secondo articolo della serie Dagger 2 per sviluppatori Android principianti. ... Se non hai letto il primo, allora sei qui .

Serie di articoli

All'inizio della serie

Nell'ultimo articolo abbiamo discusso delle dipendenze. Abbiamo imparato cos'è una dipendenza, discusso i loro tipi, l'impatto sul processo di sviluppo e la manutenibilità del progetto.

Che cos'è l' iniezione di dipendenza (DI)

In precedenza, abbiamo capito cos'è la dipendenza e come influisce su un progetto. Ora diamo un'occhiata a cos'è l'iniezione di dipendenza.
Prima di esaminare l'iniezione di dipendenza, dobbiamo capire come evitare la trappola di essere circondati da dipendenze. Il problema dei legami forti (forte dipendenza) come gli Estranei (White Walkers). Non dobbiamo arruolarci nel loro esercito, al contrario, dobbiamo trovare un modo per sconfiggerli.

media

Strategia per risolvere il problema dei legami forti (hard dependency) o il problema degli Estranei

Abbiamo bisogno di un piano chiaro per affrontare o prevenire legami forti. Questa strategia o piano è chiamata iniezione di dipendenza (DI) . In altre parole, per uccidere l'Estraneo, devi bruciarlo o usare un'arma di vetro di drago. Allo stesso modo, per evitare legami forti, è necessario utilizzare l'iniezione di dipendenza.
L'iniezione di dipendenza è solo un metodo per evitare relazioni forti. Ci sono molti altri modi. Per lo sviluppo Android, questo metodo è considerato il più semplice e molti progetti su larga scala utilizzano una strategia di iniezione delle dipendenze.

Metodo di iniezione delle dipendenze

L'iniezione di dipendenza è una tecnica in cui un oggetto espone le dipendenze di un altro oggetto. Una dipendenza è un oggetto che possiamo usare (un servizio ). L'iniezione (iniezione) è il trasferimento di una dipendenza a un oggetto dipendente ( client ), che utilizzerà questa dipendenza. Il servizio fa parte dello stato del cliente. La fornitura di un servizio al client anziché consentire al client di creare o trovare un servizio è un requisito di base del modello di progettazione Dependency Injection (DI) .
Confrontalo con Game of Thrones. Cersei si sta preparando per una grande guerra. Invece di bruciare tutti i soldi del suo regno, cerca di ottenere un prestito dalla banca di ferro di Braavos. In questa situazione, il denaro è dipendenza. Tutte le case hanno bisogno di soldi per fare la guerra. Pertanto, un oggetto esterno (banco di ferro) inietterà dipendenza (denaro) da oggetti dipendenti (case).
In altre parole, l'iniezione di dipendenza si basa sul concetto di inversione del controllo , che dice che una classe dovrebbe ricevere le sue dipendenze dall'esterno. In poche parole, nessuna classe dovrebbe creare un'istanza di un'altra classe, ma dovrebbe ricevere tutte le istanze dalla classe di configurazione.

Esempio 1

Smetti di parlare. Smontiamo il codice. Diamo un'occhiata a un piccolo esempio con due scenari. Nel primo scenario, creeremo diverse classi con dipendenze rigide , ovvero senza utilizzare l'iniezione di dipendenza. Quindi, seguendo il modello di iniezione di dipendenza, ci liberiamo dei legami forti.

Scenario 1. Senza usare l'iniezione di dipendenza

Problema: Battle bastard - Starkey (Starks) Bolton (Boltons) si preparano alla guerra per catturare il Nord. Dobbiamo prepararli e portarli in guerra.

media

Poiché l'esempio può includere molte case, creiamo un'interfaccia generaleHouse , includeremo i metodiprepareForWar() ereportForWar() ...

public interface House {
    void prepareForWar();
    void reportForWar();
}

Quindi, creiamo classi per le case.Starks eBoltons ... Le classi implementeranno l'interfacciaHouse ...

public class Starks implements House {
    @Override
    public void prepareForWar () {
        // something happens
        System.out.println (this.getClass (). GetSimpleName () + "prepared for war");
    }
    @Override
    public void reportForWar () {
        // something happens
        System.out.println (this.getClass (). GetSimpleName () + "reporting ..");
    }
}

public class Boltons implements House {
    @Override
    public void prepareForWar () {
        // something happens
        System.out.println (this.getClass (). GetSimpleName () + "prepared for war");
    }
    @Override
    public void reportForWar () {
        // something happens
        System.out.println (this.getClass (). GetSimpleName () + "reporting ..");
    }
}

La nota:this.getClass().getSimpleName() restituisce solo il nome della classe
Successivamente, devi portare entrambe le case in guerra. Creiamo una classeWar e chiedi a entrambe le case di prepararsi per la guerra e di denunciarla.

public class War {
    private Starks starks;
    private Boltons boltons;

    public War(){
        starks = new Starks();
        boltons = new Boltons();

        starks.prepareForWar();
        starks.reportForWar();
        boltons.prepareForWar();
        boltons.reportForWar();
    }
}

Analizzare la guerra

Considera il costruttore di classiWar ... Ha bisogno di due classi per lavorareStarks eBoltons ... Queste classi vengono create all'interno del costruttore, preparano la guerra e la segnalano.
In un'applicazione orientata agli oggetti ben progettata, ogni oggetto ha un numero minimo di responsabilità, gli oggetti si affidano ad altri per fare la maggior parte del lavoro. In questo esempio, la classeWar dipende daStarks eBoltons ... Queste sono dipendenze di classeWar ... Senza di loroWar non funzionerà. Prima che una classe possa iniziare a svolgere funzioni reali, tutte le sue dipendenze devono essere soddisfatte in qualche modo. Dipendenze di classeWar in questo esempio sono soddisfatte istanziando le classi nel costruttore.
Sebbene l'opzione di creare dipendenze all'interno del costruttore di classi funzioni abbastanza bene in piccole applicazioni, introduce degli svantaggi man mano che il progetto cresce.
In primo luogo, la classe diventa piuttosto inflessibile. Se l'applicazione deve essere eseguita su più piattaforme o in più modalità, ad esempio, è necessario sostituire la classeBoltons ad un altro o dividerlo in più oggetti. Non diventa così facile farlo.
In secondo luogo, non è possibile testare queste classi in isolamento. istanzaWar crea automaticamente altri due oggetti che verranno eventualmente testati insieme alla classeWar ... Questo può diventare un problema se uno degli oggetti dipende da una risorsa esterna costosa, ad esempio,Allies (alleati) o uno degli oggetti stesso dipende da molti altri.
Come accennato in precedenza, combattere le forti dipendenze è come combattere gli Estranei senza le armi adeguate.

Sommario

In questo articolo, abbiamo trattato in dettaglio le dipendenze e l'iniezione di dipendenza. Nessuna classe dovrebbe creare un'istanza di un'altra classe, ma dovrebbe ricevere tutte le istanze dalla classe di configurazione.
L'iniezione di dipendenza è una tecnica per risolvere o prevenire il problema dei collegamenti forti. Esponendo le dipendenze all'esterno, questo metodo rende la classe indipendente, verificabile e gestibile.
Abbiamo anche esaminato un esempio con dipendenze rigide , creando uno scenario di battaglia bastardo.

Qual è il prossimo?

Nel prossimo articolo, implementeremo la classeWar utilizzando il pattern Dependency Injection con l'approccio tradizionale.