L'inversione di dipendenza è sempre migliore?

Sì: ogni volta che sostenere il facile scambio di collaboratori sarebbe più lavoro di quanto non risparmi, allora non ne vale la pena.

In generale, ci sono pochissimi principi da seguire nel 100% dei casi. Il disaccoppiamento è generalmente buono perché consente il riutilizzo, una migliore comprensione delle basi di codice di grandi dimensioni, un'implementazione più rapida di modifiche inaspettate, ecc. Sembra particolarmente buono in confronto all'attuale pratica del settore negli anni '70 e '80, quando monolitico -le applicazioni modulari e la dipendenza assoluta e pervasiva da un solo database o provider di ricerca erano comuni. (Allora, la modularizzazione non era una cosa, e molti linguaggi di programmazione non l'hanno supportato, spesso non hai nemmeno avere una scelta di database, ecc.) Questo ha creato problemi quando i sistemi sono diventati < em> veramente grande, e nel complesso, i moderni principi dell'architettura software hanno funzionato meglio del vecchio modo di fare le cose. Per una buona approssimazione, più disaccoppiamento (a cui DI è principalmente usato) è buono.

Ma c'è sempre un punto di rendimenti decrescenti. Qualsiasi sistema dato deve essere messo fuori in un certo periodo di tempo e ad un costo limitato o non ne vale la pena. Alcuni sistemi non sono così grandi che è necessario separare tutto da qualsiasi altra cosa per capirli. A volte il rischio che un collaboratore cambierà non è abbastanza grande da giustificare l'architettura aggiuntiva necessaria per renderlo facilmente sostituibile. (Ogni mese vengono visualizzati nuovi protocolli di messaggistica, ma la nuova grande novità del prossimo anno probabilmente continuerà a funzionare su TCP / IP). Decidere se è necessario essere in grado di reagire agilmente a un potenziale cambiamento futuro si riduce a una decisione di gestione del rischio come qualsiasi altra in ingegneria.