Di recente ho lavorato a un progetto Python in cui abbiamo fatto pesantemente l'iniezione di dipendenze (perché dobbiamo fare in modo che l'app sia testabile), ma non abbiamo usato alcun framework. A volte era un po 'noioso collegare manualmente tutte le dipendenze, ma nel complesso ha funzionato benissimo.

Quando un oggetto doveva essere creato in più punti, avevamo semplicemente una funzione (a volte un metodo di classe di quell'oggetto) per creare un'istanza di produzione. Questa funzione veniva chiamata ogni volta che avevamo bisogno di quell'oggetto.

Nei test abbiamo fatto la stessa cosa: se più volte avessimo bisogno di creare una "versione di prova" di un oggetto (cioè un'istanza reale supportata da oggetti finti), avremmo avuto una funzione per creare questa "versione di prova" di una classe, da utilizzare nei test.

Come ho già detto, in genere ha funzionato bene.

Ora sto entrando in un nuovo progetto Java e stiamo decidendo se usare un framework DI o fare manualmente DI (come nel progetto precedente).

Spiega in che modo lavorare con un framework DI sarà diverso e in quali modi è migliore o peggiore dell'iniezione manuale di dipendenza "vaniglia".

Modifica: Vorrei anche aggiungere alla domanda: hai assistito a qualche progetto di "livello professionale" che esegue DI manualmente, senza un framework?

La chiave dei contenitori DI è l'astrazione . I contenitori DI astraggono questa preoccupazione del design per te. Come puoi immaginare, ha un notevole impatto sul codice, spesso tradotto in un numero inferiore di costruttori, setter, fabbriche e costruttori. Di conseguenza, rendono il tuo codice più liberamente accoppiato (a causa dell'IoC sottostante ), più pulito e più semplice. Anche se non senza costi.

sfondi

Anni fa, tale astrazione ci richiedeva di scrivere vari file di configurazione ( programmazione dichiarativa ). È stato fantastico vedere il numero di LOC diminuire sostanzialmente, ma mentre i LOCS sono diminuiti, il numero di file di configurazione è leggermente aumentato. Per progetti medi o piccoli non è stato affatto un problema, ma per progetti più grandi, avere "l'assemblaggio del codice" sparso il 50% tra descrittori di codice e XML è diventato un problema nel ... Tuttavia, il problema principale era il stesso paradigma. Era piuttosto inflessibile perché i descrittori lasciavano poco spazio alle personalizzazioni.

Il paradigma si è progressivamente spostato verso la convenzione sulla configurazione , che scambia i file di configurazione per annotazioni o attributi. Mantiene il nostro codice più pulito e semplice e ci fornisce la flessibilità che XML non è in grado di offrire.

Probabilmente, questa è la differenza più significativa rispetto a come stavi lavorando fino ad ora. Meno codice e più magia.

Sul lato negativo ...

La convenzione sulla configurazione rende l'astrazione così pesante che a malapena sai come funziona. A volte sembra magico e qui arriva un altro inconveniente. Una volta che funziona, molti sviluppatori non si preoccupano di come funziona.

Questo è un handicap per coloro che hanno imparato DI con contenitori DI. Non comprendono appieno la rilevanza dei modelli di progettazione, le buone pratiche e i principi che sono stati astratti dal contenitore. Ho chiesto agli sviluppatori se avevano familiarità con DI e i suoi vantaggi e hanno risposto: - Sì, ho usato Spring IoC -. (Che diavolo significa?!?)

Si può concordare o meno con ciascuno di questi "svantaggi". Secondo la mia modesta opinione, è d'obbligo sapere cosa sta succedendo nel tuo progetto. Altrimenti, non ne abbiamo una piena comprensione. Inoltre è sapere a cosa serve DI e avere un'idea di come implementarlo è un vantaggio da considerare.

Il lato positivo...

Produttività in una parola . I frame ci permettono di concentrarci su ciò che conta davvero. Il business dell'applicazione.

Nonostante le carenze commentate, per molti di noi (il cui lavoro è condizionato da scadenze e costi), questi strumenti sono una risorsa inestimabile. A mio avviso, questo dovrebbe essere il nostro argomento principale a favore dell'implementazione di un contenitore DI. Produttività .

analisi

Sia che implementiamo DI o container puri, i test non saranno un problema. Piuttosto il contrario. Gli stessi contenitori spesso ci forniscono le beffe per i test delle unità pronti all'uso. Nel corso degli anni ho usato i miei test come termometri. Mi dicono se ho fatto molto affidamento sulle strutture dei container. Dico questo perché questi contenitori possono inizializzare attributi privati ​​senza setter o costruttori. Possono iniettare componenti quasi in qualsiasi luogo!

Sembra allettante vero? Stai attento! Non cadere nella trappola !!

suggerimenti

Se decidi di implementare contenitori, ti consiglio vivamente di attenermi alle buone pratiche. Continuare a implementare costruttori, setter e interfacce. Applicare il framework / contenitore per usarli . Semplificherà le migrazioni possibili verso un altro framework o rimuoverà quello effettivo. Può ridurre significativamente la dipendenza dal contenitore.

Riguardo a queste pratiche:

• Iniezione delle dipendenze: Iniezione sul campo vs Iniezione del costruttore?

Quando utilizzare i contenitori DI

La mia risposta sarà distorta dalla propria esperienza, che è principalmente a favore dei contenitori DI (come ho commentato, sono fortemente concentrato sulla produttività, quindi non ho mai avuto il bisogno di DI puro. Al contrario).

Penso che troverai un interessante articolo di Mark Seeman su questo argomento, che risponde anche alla domanda su come implementare un DI puro .

Infine, se stessimo parlando di Java, prenderei in considerazione prima di dare un'occhiata a JSR330 - Dependency Injection .

Riassumendo

Vantaggi :

• Riduzione dei costi e risparmio di tempo. Produttività.
• Un numero inferiore di componenti.
• Il codice diventa più semplice e pulito.

Svantaggi :

• DI è delegato a librerie di terze parti. Dobbiamo essere consapevoli dei loro compromessi, punti di forza e debolezza.
• Curva di apprendimento.
• Ti fanno rapidamente dimenticare alcune buone abitudini.
• Aumento delle dipendenze del progetto (più lib)
• I contenitori basati sulla riflessione richiedono più risorse (memoria). Questo è importante se siamo limitati dalle risorse.

Differenze con DI puro :

• Meno codice e più file di configurazione o annotazioni.

Nella mia esperienza, un framework di iniezione di dipendenza porta a una serie di problemi. Alcuni problemi dipenderanno dal framework e dagli strumenti. Potrebbero esserci delle pratiche che mitigano i problemi. Ma questi sono i problemi che ho colpito.

Oggetti non globali

In alcuni casi, si desidera iniettare un oggetto globale: un oggetto che avrà solo un'istanza nell'applicazione in esecuzione. Questo potrebbe essere un MarkdownToHtmlRendererer, a DatabaseConnectionPool, l'indirizzo per il tuo server API, ecc. In questi casi, i framework di iniezione delle dipendenze funzionano in modo molto semplice, basta aggiungere la dipendenza necessaria al costruttore e il gioco è fatto.

Ma che dire degli oggetti che non sono globali? Cosa succede se è necessario l'utente per la richiesta corrente? Cosa succede se è necessaria la transazione del database attualmente attiva? E se fosse necessario l'elemento HTML corrispondente al div che contiene un modulo in cui è una casella di testo che ha appena generato un evento?

La soluzione che ho visto impiegata dai framework DI è costituita da iniettori gerarchici. Questo rende il modello di iniezione più complicato. Diventa più difficile capire cosa verrà iniettato da quale livello della gerarchia. Diventa difficile dire se un determinato oggetto esisterà per applicazione, per utente, per richiesta, ecc. Non puoi più semplicemente aggiungere le tue dipendenze e farlo funzionare.

biblioteche

Spesso vorrai avere una libreria di codice riutilizzabile. Ciò includerà anche le istruzioni su come costruire oggetti da quel codice. Se si utilizza un framework di iniezione delle dipendenze, questo includerà in genere regole vincolanti. Se desideri utilizzare la libreria, aggiungi le loro regole di associazione alle tue.

Tuttavia, possono derivare vari problemi. Puoi finire con la stessa classe associata a implementazioni diverse. La biblioteca potrebbe aspettarsi che esistano determinati binding. La libreria potrebbe sovrascrivere alcuni binding predefiniti, facendo sì che il tuo codice faccia qualcosa di strano. Il codice potrebbe sovrascrivere un po 'di associazione predefinita causando operazioni strane con il codice della libreria.

Complessità nascosta

Quando scrivi manualmente le fabbriche, hai un'idea di come le dipendenze dell'applicazione si incastrano. Quando si utilizza un framework di iniezione delle dipendenze, non si vede questo. Invece, gli oggetti tendono a crescere sempre più dipendenze, prima o poi tutto dipende praticamente da tutto.

Supporto IDE

Il tuo IDE probabilmente non capirà il framework di iniezione delle dipendenze. Con le fabbriche manuali, puoi trovare tutti i chiamanti di un costruttore per capire tutti i luoghi in cui l'oggetto potrebbe essere costruito. Ma non troverà le chiamate generate dal framework DI.

Conclusione

Cosa otteniamo da un framework di iniezione di dipendenza? Riusciamo a evitare alcune semplici placche di caldaia necessarie per creare un'istanza di oggetti. Sono tutto per eliminare la piastra della mente semplice. Tuttavia, mantenere una semplice caldaia è facile. Se stiamo per sostituire quella piastra della caldaia, dovremmo insistere per sostituirla con qualcosa di più semplice. A causa delle varie questioni che ho discusso in precedenza, non credo che i quadri (almeno così come sono) siano adatti al conto.

Java + dependency injection = framework richiesto?

No.

Cosa mi acquista un framework DI?

La costruzione di oggetti avviene in un linguaggio che non è Java.

Se i metodi di fabbrica sono abbastanza buoni per le tue esigenze, puoi fare DI in java completamente senza framework in pojo java autentico al 100%. Se le tue esigenze vanno oltre, hai altre opzioni.

I modelli di design di Gang of Four realizzano molte grandi cose ma hanno sempre avuto punti deboli quando si trattava di modelli di creazione. Java stesso ha alcuni punti deboli qui. I framework DI aiutano davvero con questa debolezza creazionale più che con le iniezioni reali. Sai già come farlo senza di loro. Quanto ti faranno bene dipende da quanto aiuto ti serve per la costruzione degli oggetti.

Ci sono molti schemi creativi emersi dopo la Banda dei Quattro. Il costruttore di Josh Bloch è un meraviglioso trucco per la mancanza di parametri nominati di Java. Oltre a ciò ci sono i costruttori iDSL che offrono molta flessibilità. Ognuno di questi rappresenta un lavoro significativo e una piastra di cottura.

Frameworks può salvarti da alcuni di questo tedio. Non sono privi di inconvenienti. Se non stai attento puoi trovarti dipendente dal framework. Prova a cambiare framework dopo averne usato uno e vedi di persona. Anche se in qualche modo mantieni l'XML o le annotazioni generiche, puoi finire per supportare quelle che sono essenzialmente due lingue che devi menzionare fianco a fianco quando pubblicizzi lavori di programmazione.

Prima di innamorarti troppo della potenza dei framework DI, prenditi del tempo e studia altri framework che ti offrono funzionalità per le quali potresti altrimenti pensare di aver bisogno di un framework DI. Molti si sono ramificati oltre il semplice DI . Considera: Lombok , AspectJ e slf4J . Ognuno si sovrappone ad alcuni framework DI ma ognuno funziona bene da solo.

Se il testing è davvero la forza trainante dietro questo, ti preghiamo di esaminare: jUnit (qualsiasi xUnit davvero) e Mockito (qualsiasi davvero finto) prima di iniziare a pensare che un framework DI dovrebbe prendere il controllo della tua vita.

Puoi fare quello che ti piace, ma per un lavoro serio preferisco una cassetta degli attrezzi ben popolata a un coltellino svizzero. Vorrei che fosse più facile disegnare queste linee, ma alcune hanno lavorato sodo per sfocarle. Niente di male, ma può rendere queste scelte difficili.

La creazione di classi e l'assegnazione di dipendenze fa parte del processo di modellazione, le parti divertenti. È il motivo per cui alla maggior parte dei programmatori piace programmare.

Decidere quale implementazione verrà utilizzata e come vengono costruite le classi è una cosa che dovrà essere implementata in qualche modo e fa parte della configurazione dell'applicazione.

Scrivere manualmente fabbriche è un lavoro noioso. I framework DI facilitano la risoluzione automatica delle dipendenze che possono essere risolte e richiedono una configurazione per quelle che potrebbero non esserlo.

L'uso degli IDE moderni consente di navigare attraverso i metodi e i loro usi. Avere fabbriche scritte manualmente è abbastanza buono, perché puoi semplicemente evidenziare il costruttore di una classe, mostrarne gli usi e ti mostrerà tutti i luoghi dove e come viene costruita la classe specifica.

Ma anche con DI framework, puoi avere un posto centrale, come la configurazione della costruzione di oggetti grafici (OGCC da ora in poi), e se una classe dipende da dipendenze ambigue, puoi semplicemente guardare OGCC e vedere come viene costruita una classe specifica proprio qui.

Potresti obiettare che tu pensi che poter vedere gli usi di un costruttore specifico sia un grande vantaggio. Direi che ciò che viene meglio per te non è solo soggettivo, ma deriva principalmente dall'esperienza personale.

Se avessi sempre lavorato su progetti che si basavano su framework DI, lo sapevi davvero solo e quando volevi vedere una configurazione di una classe, guardavi sempre a OGCC e non provavi nemmeno a vedere come vengono usati i costruttori , perché sapresti comunque che le dipendenze sono tutte cablate automaticamente.

Naturalmente, i framework DI non possono essere utilizzati per tutto e di tanto in tanto dovrai scrivere un metodo di fabbrica o due. Un caso molto comune è la costruzione di una dipendenza durante l'iterazione su una raccolta, in cui ogni iterazione fornisce un flag diverso che dovrebbe produrre un'implementazione diversa di un'interfaccia altrimenti comune.

Alla fine molto probabilmente dipenderà da quali sono le tue preferenze e cosa sei disposto a sacrificare (o scrivendo fabbriche o trasparenza).

Esperienza personale (avviso: soggettivo)

Parlando come sviluppatore di PHP, anche se mi piace l'idea dietro i framework DI, li ho usati solo una volta. Fu allora che un team con cui stavo lavorando doveva distribuire un'applicazione molto rapidamente e non potevamo perdere tempo a scrivere fabbriche. Quindi abbiamo semplicemente raccolto un framework DI, configurato e funzionato, in qualche modo .

Per la maggior parte dei progetti, mi piace che le fabbriche vengano scritte manualmente perché non mi piace la magia nera che accade all'interno dei framework DI. Ero il responsabile della modellistica di una classe e delle sue dipendenze. Sono stato io a decidere perché il design si presenta così. Quindi sarò colui che costruirà correttamente la classe (anche se la classe prende dipendenze difficili, come classi concrete invece di interfacce).

Personalmente non uso contenitori DI e non mi piacciono. Ho un paio di ragioni in più per questo.

Di solito è una dipendenza statica. Quindi è solo un localizzatore di servizi con tutti i suoi svantaggi. Quindi, a causa della natura delle dipendenze statiche, vengono nascoste. Non hai bisogno di affrontarli, sono già in qualche modo lì ed è pericoloso, perché smetti di controllarli.

Si rompe principi OOP , quali la coesione e David West Lego-mattone metafora oggetto s'.

Quindi costruire l'intero oggetto il più vicino possibile al punto di ingresso del programma è la strada da percorrere.

Come hai già notato: a seconda della lingua che usi, ci sono diversi punti di vista, che differiscono su come affrontare problemi simili.

Per quanto riguarda l'iniezione di dipendenza, ciò si riduce a questo: l'iniezione di dipendenza non è, come dice il termine, nient'altro che mettere le dipendenze di cui un oggetto ha bisogno in quell'oggetto - in contrasto con l'altro: lasciare che l'oggetto stesso installi istanze di oggetti da cui dipende. Disaccoppi la creazione e il consumo di oggetti per ottenere una maggiore flessibilità.

Se il tuo progetto è ben strutturato, di solito hai poche classi con molte dipendenze, quindi il cablaggio delle dipendenze - a mano o da un framework - dovrebbe essere relativamente semplice e la quantità di piastra di caldaia per scrivere i test dovrebbe essere facilmente gestibile.

Detto questo, non è necessario un DI-framework.

Ma perché vuoi usare un framework?

I) Evitare il codice della caldaia

Se il tuo progetto ha dimensioni, dove senti il ​​dolore di scrivere fabbriche (e istanze) ancora e ancora, dovresti usare un DI-framework

II) Approccio declacrativo alla programmazione

Quando Java una volta stava programmando con XML , ora è: cospargere il fairydust di annotazioni e la magia accade .

Ma seriamente: vedo un chiaro vantaggio in questo. Si comunica chiaramente l'intenzione dicendo ciò che è necessario invece di dove trovarlo e come costruirlo.

tl; dr

I framework DI non rendono il tuo codebase magicamente migliore, ma aiutano a rendere il codice di bell'aspetto davvero nitido . Usalo, quando senti di averne bisogno. Ad un certo punto del tuo progetto, ti farà risparmiare tempo e prevenire la nausea.

Sì. Probabilmente dovresti leggere il libro di Mark Seemann intitolato "Dependency Injection". Descrive alcune buone pratiche. Sulla base di alcune delle tue affermazioni, potresti trarne beneficio. Dovresti mirare ad avere una radice di composizione o una radice di composizione per unità di lavoro (ad esempio, richiesta web). Mi piace il suo modo di pensare che qualsiasi oggetto che crei sia considerato una dipendenza (come qualsiasi parametro di un metodo / costruttore), quindi dovresti davvero stare attento a dove e come crei gli oggetti. Un framework ti aiuterà a mantenere chiari questi concetti. Se leggi il libro di Mark troverai molto più della semplice risposta alla tua domanda.

Sì, quando lavoro in Java, consiglierei un framework DI. Ci sono alcuni motivi per questo:

• Java ha diversi pacchetti DI estremamente buoni che offrono l'iniezione automatizzata delle dipendenze e di solito vengono forniti con funzionalità aggiuntive che sono più difficili da scrivere manualmente rispetto ai semplici DI (ad esempio dipendenze con ambito che consentono la connessione automatica tra gli ambiti generando codice per cercare quale ambito dovrebbe trovarsi utilizzare una ricerca della versione corretta della dipendenza per tale ambito, quindi ad esempio gli oggetti con ambito applicazione possono fare riferimento a quelli con ambito richiesta).

• le annotazioni java sono estremamente utili e forniscono un modo eccellente di configurare le dipendenze

• la costruzione di oggetti java è eccessivamente dettagliata rispetto a quella a cui sei abituato in Python; l'utilizzo di un framework qui consente di risparmiare più lavoro rispetto a un linguaggio dinamico.

• I framework java DI possono fare cose utili come generare automaticamente proxy e decoratori che funzionano più in Java che in un linguaggio dinamico.

Se il tuo progetto è abbastanza piccolo e non hai molta esperienza con il DI-Framework, ti ​​consiglio di non usare il framework e di farlo manualmente.

Motivo: una volta ho lavorato a un progetto che utilizzava due librerie che avevano dipendenze dirette con diversi di framework. avevano entrambi un codice specifico del framework come di-give-me-an-instance-of-XYZ. Per quanto ne so, puoi avere solo un'implementazione di-framework attiva alla volta.

con un codice come questo puoi fare più danni che benefici.

Se hai più esperienza probabilmente toglieresti il ​​frammentato da un'interfaccia (factory o servicelocator), quindi questo problema non esisterà più e il di framework farà più benefici che danno.