Iniezione delle dipendenze per componenti strettamente accoppiati

Question

Iniezione delle dipendenze per componenti strettamente accoppiati

#1 da (7 voti)

3

Sto scrivendo del codice per analizzare alcuni file (che io chiamo "assets"), e ho intenzione di strutturarlo come tre classi: AssetParser , NamespacesParser e TransfomersParser . AssetParser utilizzerà gli oggetti delle altre due classi per analizzare alcune parti delle risorse.

Voglio scrivere questo come tre classi piuttosto che una grande classe per dividere la funzionalità in frammenti gestibili (cioè io uso qualcosa come la programmazione strutturata, dove i metodi di AssetParser chiamano i metodi delle altre due classi)

La mia domanda: dovrei usare dependency injection per creare oggetti di NamespacesParser e TransformersParser classes?

Le parti del parser sono strettamente accoppiate al parser. A mio parere, è altamente improbabile che AssetParser utilizzi altri subparser al posto di NamespacesParser e TransformersParser . Quindi sembra che l'iniezione di dipendenza non sia necessaria qui. (Posso usare solo new per creare oggetti di NamespacesParser e TransformersParser .)

Uno dei motivi per usare l'iniezione di dipendenza è che permette facilmente di creare NamespacesParser e TransformersParser singletons (se voglio usare i singleton). Ci sono altri motivi?

dependency-injection design-patterns

posta porton 14.02.2018 - 20:13

fonte

1 risposta

Leggi altre domande sui tag dependency-injection design-patterns

Dovresti sborsare un repo se lo stai trasferendo in un'altra lingua? Come si strutturano i casi di test su oggetti con più gradi di libertà?

score 7 · Accepted Answer

DI non è un fine in sé, è un mezzo per un fine.

Se la modifica dei parser secondari non è (attualmente) un obiettivo per il tuo parser di asset finali, la domanda che devi porsi è: può DI aiutare rendendo il test dell'unità più semplice?

Quindi questo si riduce a una decisione molto semplice:

se riesci a pensare a un test unitario significativo dove la sostituzione dei sub parser con alcuni oggetti finti ti aiuterà a testare il parser delle risorse in un isolamento migliore, allora DI avrà senso.
se, tuttavia, puoi scrivere tutti i test necessari senza DI, quindi non sarà richiesto.

Dovrei aggiungere che la tua idea di "usare DI per rendere più facile la creazione di singleton" sembra più una ragione contro che usa DI: i singleton sono solo uno strumento il cui utilizzo ha bisogno di una giustificazione per conto proprio . A causa della loro natura globale, molte persone li considerano antipattern. Quindi, nel dubbio se ne hai bisogno, meglio evitarli.

Nota quando inserisci parti della funzionalità parser in queste classi di sub parser e crei queste ultime nel costruttore di AssertParser , sarà probabilmente facile aggiungere DI in un secondo momento con un semplice refactoring quando ne avrai bisogno.