In che modo l'iniezione di dipendenza non si limita a spostare la complessità in una classe separata?

Questa settimana ho cercato di utilizzare il framework Typhoon per l'iniezione di dipendenza. Capisco che separare la costruzione di oggetti sia utile per sostituire componenti arbitrari con derisioni durante i test delle unità, e finora ho visto benefici da questo da solo.

Ma non posso fare a meno di pensare che dove prima avevo una gigantesca classe di controller di vista che aveva decine di importazioni di intestazione, ora ho una classe di fabbrica enorme che ha decine di importazioni di intestazione. Dovrei evitare di avere un'enorme classe di fabbrica?

dependency-injection

— Vincitore
fonte

Tra un decennio mi aspetto che DI prenda il sopravvento sulla lista dei bashing da Singleton, ma questa volta per buoni motivi. Ha alcuni buoni usi ma suggerisco di fare molta attenzione nel valutare l'impatto.

— Balog Pal

Non penso che l'iniezione di dipendenze sia un modo per ridurre la complessità ma un modo per evitare dipendenze implicite (uso di simboli globali / variabili libere) a favore di dipendenze esplicite (usare parametri espliciti / variabili legate). Quindi, la complessità è ancora lì, ma sei costretto a gestirla perché la rendi esplicita nelle firme del metodo / costruttore.

— Giorgio,

Si noti che praticamente qualsiasi sistema per l'organizzazione del codice potrebbe essere descritto come "spostando la complessità altrove". Non si tratta di rimuovere la complessità quanto di organizzarla nel modo più logico e utile.

Se devi importare 50 intestazioni, devi farlo da qualche parte. DI ti aiuta con un modo più semplice per testare l'unità del tuo codice.

— BЈовић

Quindi, stai dicendo che ora il tuo controller è focalizzato sul controllo e la tua fabbrica di importazione di header è focalizzata sulle importazioni di header? Come può mai essere una cosa negativa, che tu stia usando un framework DI o no?

— pdr,

Risposte:

L'iniezione di dipendenza aiuta semplicemente a definire come un oggetto conosce un altro oggetto dipendente. Non ti aiuterà a ridurre la complessità complessiva del sistema. Se avevi bisogno di decine di importazioni prima di DI, avrai comunque bisogno di decine di importazioni dopo. La differenza è che queste importazioni saranno in una posizione (classe) che ha più senso (fabbrica, costruttore, ecc.).

Consentendo che le dipendenze vengano fornite attraverso un costruttore o un metodo, ti concedi la flessibilità di fornire un oggetto diverso, ma ancora valido, dipendente alla tua classe e aumentare la coesione di detta classe rimuovendo le preoccupazioni.

Esistono diversi principi simili e spesso utilizzati insieme: Dependency Injection (DI), Inversion of Control (IoC) e Dependency Inversion Principle (DIP)

Da questo articolo http://martinfowler.com/articles/dipInTheWild.html

DI riguarda il cablaggio, IoC riguarda la direzione e DIP riguarda la forma

— Seth M.
fonte

+1, per l'ultima citazione. È il miglior chiarimento di questi 3 concetti che le persone spesso fraintendono.

— Haylem,

L'articolo collegato sopra è davvero eccezionale. Una spiegazione sufficientemente profonda e molto chiara.

— DemetriKots,

L'iniezione di dipendenza non riduce la complessità, ma aumenta la gestibilità attraverso la separazione delle preoccupazioni e la riduzione dell'accoppiamento.

Ma non posso fare a meno di pensare che dove prima avevo una gigantesca classe di controller di vista che aveva decine di importazioni di intestazione, ora ho una classe di fabbrica enorme che ha decine di importazioni di intestazione. Dovrei evitare di avere un'enorme classe di fabbrica?

Dovresti evitare lezioni "gigantesche", punto. Supponiamo quindi di aver suddiviso il controller di visualizzazione in classi più piccole e più gestibili. Ora tutti sono responsabili di procurarsi le proprie dipendenze. DI ti aiuta a spostare questa gestione delle dipendenze da tutte quelle classi in una classe factory / di configurazione che è responsabile solo della gestione delle dipendenze - vedi Principio di responsabilità singola. E mentre sarà sicuramente molto meno "humongous" rispetto al controller di visualizzazione originale, se diventa troppo grande hai sempre la possibilità di dividerlo in classi di gestione delle dipendenze più piccole che sono responsabili di diverse parti dell'applicazione.

— Michael Borgwardt
fonte

Nelle parole di laici:

L'iniezione di dipendenza sposta la complessità dove fa meno male.

EDIT per @gnat: DI non sta semplicemente spostando la complessità in una classe separata, ma la sta spostando dove causa meno danni.

— Tulains Córdova
fonte

come risponde alla domanda posta?

— moscerino

@gnat ha aggiunto una modifica, la mia risposta spiega a mio avviso come DI non sta semplicemente spostando la complessità in una classe separata.

— Tulains Córdova,