Iniezione delle dipendenze - numero di odori dei parametri iniettati

-1

stasera pensavo a cosa racconta del design e dell'architettura delle classi con molti oggetti iniettati. Sto prendendo in considerazione specificamente setter e constructor injection.

I sostenitori dell'iniezione setter usano sempre un argomento di complessità dell'iniezione del costruttore in opposizione alla semplicità del setter, specialmente nei casi in cui il numero di parametri nel costruttore cresce, ma questo è un argomento diverso.

Penso che un gran numero di parti iniettate suggeriscano una violazione della singola responsabilità dell'oggetto. Ci potrebbero essere fiocchi di neve speciali, ma in generale una buona metrica, penso.

Ora come combatterlo specialmente nei casi in cui la profondità verticale dei costruttori è maggiore di diciamo 3?

Sto pensando ad alcune linee guida per combattere questi casi.

Spiegazione: profondità verticale

Diciamo che abbiamo un'architettura complessa, in cui alcune classi UniversalHelper / IUniversalHelper sono create nella radice o vicino alla radice e l'istanza sta permeando nel grafico sempre più in profondità. Non considero i logger come tali oggetti, hanno uno scopo specifico che deve permeare attraverso l'intera architettura, ma qualcosa come l'accesso universale ai dati. Si ritiene che debba essere usato qualcosa come gestori di dati specifici per casi specifici di accesso ai dati e quindi oggetto UniversalHelper non sarebbe più permeante attraverso l'architettura, la sua profondità verticale sarebbe limitata, invece la profondità orizzontale crescerebbe in un punto specifico, dove UniversalHelper sarebbe utilizzato per creare specifici gestori di dati, oggetti con responsabilità raffinata, più limitata o limitata verso un singolo obiettivo di responsabilità.

Ovviamente, dove è permesso a un oggetto universale di permeare l'intera architettura, prima o poi ci saranno due, tre, cinque :). È logico perché ritiene che gli sviluppatori stagionati sul progetto dato siano uno stile di vita utile, corretto e testato e che i nuovi sviluppatori che si uniscono a progetti specifici siano un segno, è sempre stato così, se lo fai nello stesso modo , ha una maggiore probabilità di passare la revisione del codice da colleghi esperti sul progetto ...

    
posta ipavlu 26.09.2017 - 12:12
fonte

1 risposta

1

In linea di principio, è possibile eseguire l'iniezione di dipendenza in due modi: passando tutte le classi iniettate al costruttore che crea un'istanza, o avendo un metodo globale che fornisce tutte le classi che possono essere iniettate a chiunque ne abbia bisogno. (Sono sicuro che qualcuno può trovare una terza via: -)

Quest'ultimo metodo significa che un'istanza deve semplicemente afferrare esattamente le classi iniettate di cui ha bisogno, e che quindi sa.

Il primo metodo ha il problema che se l'istanza ha dipendenze (se crea altre istanze), allora deve passare le classi giuste iniettate ai costruttori di queste istanze. E queste potrebbero essere iniezioni a cui l'istanza non si cura e non dovrebbe preoccuparsi.

Caso peggiore: si aggiunge una classe I da iniettare in istanze di una classe A. Quindi qualsiasi costruttore che crea quelle istanze di A deve passare quell'iniezione I. Quindi tutte le classi B le cui istanze creano istanze di A, I. Quindi tutte le classi C di cui le istanze creano istanze di B hanno bisogno I. E così via.

Questo è il motivo per cui preferisco di gran lunga "ogni uomo per sé": qualsiasi istanza che necessiti un'iniezione dovrebbe ottenerla da qualche parte.

    
risposta data 15.10.2017 - 20:42
fonte

Leggi altre domande sui tag