Esistono prove del fatto che l'uso dell'iniezione di dipendenza migliora i risultati nell'ingegneria del software?

Nonostante la sua popolarità, ci sono prove empiriche che dimostrano che l'iniezione di dipendenza (e / o l'uso di un contenitore DI) aiuta, diciamo, a ridurre il numero di bug, migliorare la manutenibilità o aumentare la velocità di sviluppo su progetti software nella vita reale?

TLDR

I dati empirici sono irrilevanti. Strumenti e pratiche (come DI) risolvono problemi particolari . Comprendi i tuoi problemi, impara come usare gli strumenti e diventerà ovvio quando uno strumento è prezioso - e sarai in grado di spiegare i risultati molto più profeticamente di qualsiasi dato generalizzato, aggregato, empirico.

E ora, con molta più verbosità ...

Esistono prove empiriche?

Certo, probabilmente. O almeno forse. Ma a chi importa? Non è rilevante

Un'analisi statistica costi-benefici di DI può essere interessante a livello accademico, ma non prevede necessariamente il successo individuale. I risultati aggregati nascondono singoli successi e fallimenti. E potrei sostenere che i dati relativi alle pratiche "evangeliche" sono particolarmente velenosi. Queste discipline tendono ad attrarre sia zeloti che sciocchi, entrambi i quali oscurano l'impatto netto di un'implementazione "pura", e in entrambi i casi potresti essere!

Quindi, come facciamo a sapere che l'iniezione di dipendenza è preziosa ?

Buona domanda! GRANDE domanda, in effetti. E sono con te - odio perdere tempo e sforzi mentali su "best practice" dogmatiche che nessuno può giustificare. Quindi, sono felice che tu l'abbia chiesto.

Uhh. Ma, ecco il problema imbarazzante ... In generale termini, si non lo sai. E, ancora più imbarazzante, il tuo codice potrebbe non migliorare in alcun modo introducendo DI.

GASP!

    ⊙▃⊙     . . .      (╯°□°)╯︵ ┻━┻

...

Quindi, forse ora ti stai chiedendo ...

Perché dovrei preoccuparmi delle cose che non sono state provate e non è vero !?

Prima di tutto, andiamo tutti, su ogni lato del dibattito, a sistemarci. Posso assicurarti che tra dogmatismo e scetticismo c'è un bellissimo paradiso di ragione e intimità. (E l'occasionale post SE.SE eccentrico.) E il POAP può condurti lì.

... Con questo intendo, il Principio di applicare i principi :

Principi, schemi e pratiche non sono scopi finali. La corretta e corretta applicazione di ciascuno è quindi ispirata e limitata da uno scopo superiore e più finale.

Devi capire perché stai facendo quello che stai facendo!

(Il POAP non è esente dal POAP.)

^{(Direi "enfasi sul mio", ma proviene comunque dal mio "blog". Quindi, è tutto mio!)}

Permettetemi di ribadire il punto principale qui: è necessario capire perché stai facendo quello che stai facendo.

E forse per chiarire, di solito non ha senso prendere un dato "qualcosa" (come Dependency Injection) e usarlo senza già capire quale problema risolve - per te in particolare. Se capisci i tuoi problemi e come funziona il "qualcosa" (come DI), sarà in qualche modo "ovvio" quanto sia utile il "qualcosa", indipendentemente da ciò che suggeriscono i dati generalizzati, aggregati, empirici.

Se la disponibilità di DI o un -helpfulness a voi non è evidente - o almeno oltre le capacità di ragionamento - si sia non si capisce DI, o non si capisce i propri problemi.

Consideriamo una "parabola" del mondo reale.

Dobbiamo costruire una scatola. Abbiamo il legno. Abbiamo le unghie. E, abbiamo due strumenti: un martello da carpentiere standard e un cacciavite .

Ora, potremmo avere alcuni dati empirici ampi per mostrare che le scatole costruite con cacciaviti sono scatole complessivamente molto più robuste, rispetto a quelle costruite con martelli. Ma, se provi ad avvitare quei chiodi, non finirai affatto con una scatola. E, se provi a schiacciarli con il cacciavite, potresti eventualmente inserirli; ma richiederà molto più tempo e fatica, e il risultato finale sarà meno preciso (e robusto) rispetto al semplice utilizzo del martello.

E, se hai mai visto qualcuno usare uno degli strumenti prima e se hai capito come appare una scatola, la decisione è ovvia.

Telecinesi!

Err ... hmm ...

Sì, quindi, quale problema risolve l'iniezione di dipendenza?

Funziona per impedire il codice rigido, non configurabile, che spesso è quindi non testabile .

Lo fa consentendo al codice di invocazione di decidere con quali oggetti opera un modulo. E so che ci stai pensando, e hai ragione: questo non è nemmeno un concetto remoto. I parametri metodo / funzione sono esistiti da quando si è verificata l'algebra.

Abbiamo iniziato a evangelizzare il passaggio dei parametri di base, chiamandolo "Iniezione di dipendenza", una volta che abbiamo accumulato ed ereditato abbastanza codice per vedere i nostri squilibri. Le montagne di codice su cui eravamo seduti non potevano essere facilmente modificate, testate o persino riutilizzate , semplicemente perché le dipendenze erano nascoste.

Quindi, la crociata zelante per l'iniezione di dipendenza ...

K. Ma posso passare degli argomenti bene. Perché i quadri ?

Da quanto ho capito, i framework DI risolvono principalmente il problema dell'accumulo di scaldabagni (a causa di DI zelanti, IMO), in particolare quando ci sono dipendenze "predefinite" standard per tutti i moduli che li richiedono. I framework DI fanno cose magiche (potenzialmente anche cattive!) Per far scivolare quelle dipendenze predefinite quando non sono esplicitamente passate al punto di invocazione. (Stesso effetto di un Service Locator se utilizzato in questo modo, attenzione!)

L'iniezione di dipendenza, in quanto "disciplina", in realtà è davvero difficile da ottenere. Non si tratta di usare DI o no; si tratta di sapere quali dipendenze potrebbero cambiare o necessitano di deridere e iniettare quelle . E poi, si tratta di decidere se DI si adatta meglio di qualche alternativa, come Service Location ...

Ma, l'invitiamo a Google che , magari vedere questa risposta SO , eventualmente, parlare con uno sviluppatore super-esperto e di successo nel proprio settore, e gli esempi specifici pubblicare a CR.SE .

Ho cercato Google, Google Scholar, ACM e IEEE Ecco i documenti che sono stato in grado di trovare:

• Framework di iniezione delle dipendenze: un miglioramento della testabilità? . Sostiene che "testabilità" può essere definita come "bassa coesione". Afferma che DI porta a una coesione più bassa, una coesione più bassa è correlata a una copertura di test più elevata e che una copertura di test più elevata è correlata con più guasti riscontrati. Dice che, in base a ciò, DI migliora la testabilità.

  Non mi piace per un paio di ragioni. Prima di tutto, sta dicendo "A è correlato a B, B è correlato a C, quindi A causa C", che è un paio di passaggi nella logica che non vedo come ben supportati dal documento. In secondo luogo, ammette che sta solo misurando "sottoparti della testabilità" e che la "testabilità" in generale non è qualcosa di facile da definire. Infine, la loro misura della testabilità è definita in termini di numero di dipendenze iniettate!

• Effetti dell'iniezione di dipendenza sulla manutenibilità . Confrontano i progetti che utilizzano DI con i progetti che non utilizzano DI che hanno trovato su SourceForge e vedono se ci sono differenze nelle metriche di coesione. Per ridurre la distorsione, hanno abbinato i progetti per essere il più simile possibile. Alla fine, hanno visto segnali che i progetti con molti DI erano in qualche modo meno accoppiati rispetto ai progetti con solo un piccolo DI. Tuttavia, sembra che non vi fosse alcuna differenza significativa nella coesione tra i progetti DI e la loro coppia non DI, quindi potrebbe essere una conseguenza dei domini specifici. Elencano "nessuna correlazione" come risultato principale e il "forse aiuta un po '?" come argomento per ulteriori studi.

• Valutazione empirica dell'impatto dell'iniezione di dipendenza sullo sviluppo di applicazioni di servizi Web . L'abstract non spiega davvero cosa stanno cercando. Ho scavato e letto una prestampa e per quanto ne so in realtà riguarda quanto bene gli strumenti automatizzati possono scoprire i servizi. I servizi scritti in stile DI sono stati scoperti più facilmente. Inoltre, cita il precedente studio che ho elencato come prova empirica che DI riduce l'accoppiamento, che è l'opposto di quanto affermato da quel documento.

Per questi tre articoli (e per An Empirical Study in Use of Dependency Injection in Java , che riguarda solo il rilevamento) ho dato seguito a tutti gli articoli che li citavano, nessuno dei quali riguardava la determinazione dell'efficacia di DI. Alla luce di tutto ciò, sono fiducioso nel dire che no , non abbiamo ancora prove empiriche sul fatto che DI migliori o meno la qualità del software.