Iniezione delle dipendenze e contenitori IOC in un progetto chiuso

4

Ha senso assemblare il mio progetto con contenitori di iniezione di dipendenza se sono l'unico che utilizzerà il codice di quel progetto?

La domanda è venuta quando ho letto questo articolo del CIO link

La giustificazione per l'utilizzo dell'iniezione di dipendenza in questo articolo è che gli amici possono riutilizzare una classe e sostituire le classi dipendenti con le proprie classi perché vengono iniettate e non istanziate nella classe.

Lo userei solo per iniettare oggetti dove sono necessari invece di passarli attraverso i livelli al loro obiettivo. (Che non è poi così male che ho imparato qui: È una cattiva pratica passare le istanze attraverso diversi livelli? )

(Forse riutilizzerò parti del progetto, chissà, ma non so se questa è una buona giustificazione)

    
posta Puckl 01.10.2012 - 19:50
fonte

2 risposte

6

Come viene consumato il codice e quante persone stanno lavorando al progetto sono ortogonali alla decisione di utilizzare i contenitori IoC o meno.

Sono un meccanismo per fornire implementazioni sconosciute (e possibilmente modificabili dopo la distribuzione) per una data interfaccia, spesso tramite la configurazione. Hai bisogno di quel meccanismo? Quindi considera di usarli. In caso contrario, non farlo.

Personalmente trovo che i contenitori simili a Spring siano spesso più problemi del problema che stanno risolvendo. Fornire dipendenze tramite un parametro costruttore o una fabbrica semplice spesso sono abbastanza buone. Tendono ad essere più facili da eseguire il debug e molto meno inclini agli errori a causa della mancanza di configurazione.

    
risposta data 01.10.2012 - 19:58
fonte
2

Per me DI è un buon modo per mantenere le lezioni semplici e con una sola responsabilità. Inoltre, quando li testi (unitamente), ringrazierai le loro dipendenze (probabilmente i mock) sono facilmente iniettabili.

    
risposta data 01.10.2012 - 22:12
fonte