Come spiegare l’iniezione di dipendenza a un bambino di 5 anni?

Qual è un buon modo per spiegare l’ iniezione di dipendenza ?

Ho trovato diversi tutorial su Google, ma nessuno di loro presuppone che il lettore sia solo un principiante Java. Come lo spiegheresti a un novizio?

Ti do un’iniezione di dipendenza per bambini di cinque anni.

Quando vai e tiri fuori le cose dal frigorifero, puoi causare problemi. Potresti lasciare la porta aperta, potresti ottenere qualcosa che mamma o papà non vogliono che tu abbia. Potresti anche cercare qualcosa che non abbiamo nemmeno o che è scaduto.

Quello che dovresti fare è affermare un bisogno, “Ho bisogno di qualcosa da bere a pranzo”, e poi ci assicureremo che tu abbia qualcosa quando ti siedi per mangiare.

Che dire di questo?

Se hai un Employee class e questo dipendente ha un Address , puoi definire la class Employee come segue:

 class Employee { private Address address; // constructor public Employee( Address newAddress ) { this.address = newAddress; } public Address getAddress() { return this.address; } public void setAddress( Address newAddress ) { this.address = newAddress; } } 

Tutto sembra a posto finora.

Questo codice mostra una relazione HAS-A tra il dipendente e il suo indirizzo, va bene.

Ora, questa relazione HAS-A creava una dipendenza tra di loro. Il problema si presenta all’interno del costruttore.

Ogni volta che vuoi creare un’istanza Employee hai bisogno di un’istanza Address :

  Address someAddress = .... Employee oscar = new Employee( someAddress ); 

Lavorare in questo modo diventa problematico soprattutto quando si desidera eseguire il test dell’unità.

Il problema principale si presenta quando è necessario testare un particolare object, è necessario creare un’istanza di un altro object e molto probabilmente è necessario creare un’istanza di un altro object per farlo. La catena potrebbe diventare ingestibile.

Per evitare ciò, potresti cambiare il costruttore in questo modo:

  public Employee(){ } 

Usando un costruttore no args.

Quindi puoi impostare l’indirizzo quando vuoi:

  Address someAddress = .... Employee oscar = new Employee(); oscar.setAddress( someAddress ); 

Ora, questo può essere un trascinamento, se si hanno diversi attributi o se gli oggetti sono difficili da creare.

Eppure, pensa a questo, diciamo, aggiungi l’attributo Department :

  class Employee { private Address address; private Department department; .... 

Se hai 300 dipendenti e tutti hanno bisogno di avere lo stesso dipartimento, e in più lo stesso dipartimento deve essere condiviso tra alcuni altri oggetti (come l’elenco di reparti dell’azienda, o i ruoli che ogni reparto ha, ecc.) avere difficoltà con la visibilità dell’object Department e condividerlo attraverso tutta la rete di oggetti.

Che cosa sia la Dependency Injection per aiutarti a, beh, “iniettare” queste dipendenze nel tuo codice. La maggior parte dei framework ti permette di farlo specificando in un file esterno, quale object deve essere iniettato.

Assumi un file di proprietà per un iniettore fittizio di dipendenze:

  #mock employee employee.address = MockAddress.class employee.department = MockDepartment.class #production setup employee.address = RealAddress.class employee.department = RealDepartment.class 

Definirai cosa iniettare per un determinato scenario.

Ciò che il framework Dependency Injector farà è impostare gli oggetti corretti per te, in modo da non dover codificare setAddress o setDepartment . Ciò avverrebbe mediante riflessione, generazione di codice o altre tecniche.

Pertanto, la prossima volta che è necessario testare la class Employee , è ansible iniettare oggetti mock Address e Departments senza dover codificare tutto il set / get per tutto il test. Ancora meglio, puoi iniettare oggetti Address e Department reali nel codice di produzione e avere comunque la sicurezza che il tuo codice funzioni come testato.

Questo è praticamente tutto.

Ancora non penso che questa spiegazione sia adatta per un 5 anni come richiesto.

Spero che tu lo trovi ancora utile.

Quando scrivi un corso, è naturale che faccia uso di altri oggetti. Potresti avere una connessione al database, per esempio, o qualche altro servizio che usi. Questi altri oggetti (o servizi) sono delle dipendenze. Il modo più semplice per scrivere il codice è semplicemente creare e utilizzare quegli altri oggetti. Ma questo significa che il tuo object ha una relazione inflessibile con queste dipendenze: indipendentemente dal motivo per cui stai invocando il tuo object, usa le stesse dipendenze.

Una tecnica più potente è quella di essere in grado di creare il tuo object e fornirlo con le dipendenze da usare. Quindi potresti creare una connessione al database da usare, quindi consegnarla al tuo object. In questo modo, puoi creare il tuo object con dipendenze diverse in momentjs diversi, rendendo il tuo object più flessibile. Questa è l’iniezione di dipendenza, dove si “iniettano” le dipendenze nell’object.

A proposito: nello stile moderno di presentazione delle foto di flickr per illustrare concetti, questo potrebbe essere illustrato con un tossicodipendente che si sparava con la droga. Oh, aspetta, questa è dipendenza da iniezione … OK, scusa, brutto scherzo.

Non conosco tutorial semplificati, ma posso darvi una versione di quasi 25 250 parole o meno:

Con l’iniezione di dipendenza, un object non configura i propri componenti in base a cose che già conosce, piuttosto l’object è configurato da una logica di livello superiore e quindi chiama componenti che non avevano una preconcezione predefinita. L’idea è di rendere l’object più di un componente e meno di un’applicazione, spostando le attività di configurazione a un livello superiore. Ciò rende più probabile che l’object sia utile in futuro o con una configurazione diversa.

È meglio per i test, è meglio quando arriva il momento di rivedere l’applicazione. Un’implementazione tipica mette la configurazione in XML e utilizza un framework per caricare dynamicmente le classi.

Quando ricevi una nuova console Nintendo, puoi semplicemente usare i pulsanti e il touch screen per giocare.

Ma alla fabbrica Nintendo, hanno bisogno di sapere come metterne uno insieme.

Quando le persone intelligenti in fabbrica tirano fuori un Nintendo DS, sarà diverso all’interno, ma saprai comunque come usarlo.