Scelta tra Inversione dipendenza e Dipendenza "Delega" in un terzo modulo

Question

Scelta tra Inversione dipendenza e Dipendenza "Delega" in un terzo modulo

#1 da (2 voti)

5

Supponiamo che abbia MasterPackage contenente una classe Master e BlasterPackage contenente Blaster class. Poiché Master ha bisogno di un Blaster per funzionare, il livello più alto MasterPackage dipende direttamente sul% di livello inferioreBlasterPackage.

Usando Classic Dependency Inversion, si aggiungerebbe IBlaster (o AbstractBlaster ) a MasterPackage , quindi invertendo la dipendenza tra i pacchetti.

Ma di fronte a questo problema, mi sono reso conto che potevo creare un terzo pacchetto - chiamiamolo MasterBlasterInterfaces - e mettere lì IBlaster . Ciò "delegherebbe" la dipendenza a quel terzo, pacchetto comune, e i due pacchetti originali sarebbero ora disaccoppiati l'uno dall'altro.

Ma poi, se ho un pacchetto a livello higer chiamato ThunderDome , dovrà trattare direttamente con BlasterPackage , non è vero? Mi sembra che violi l'incapsulamento, mentre con la dipendenza diretta Master è possibile astrarre l'esistenza stessa di Blaster .

Quindi la domanda è:

Is there a good set of criteria to choose between inversion vs. delegation of dependencies? And how one vs. other impacts use of the packages by higher-level application layers?

architecture solid layers dependency-management dependency-inversion

posta heltonbiker 15.12.2015 - 13:06

fonte

1 risposta

Leggi altre domande sui tag architecture solid layers dependency-management dependency-inversion

Suggerimenti per l'ottimizzazione del codice javascript. un anno di datteri Perché Array.prototype è progettato per essere un array completamente funzionale?

score 2 · Answer 1

Invertire la dipendenza come hai descritto è OK se controlli l'altro pacchetto e se questa dipendenza diretta è accettabile. Per un sacco di software, è del tutto OK. Ma, ovviamente, questo non funziona se il tuo BlasterPackage è una libreria esterna su cui fai affidamento.

La magia dell'introduzione di un'interfaccia IBlaster è che MasterPackage e BlasterPackage possono funzionare insieme senza una relazione di dipendenza diretta e senza essere scritti dalla stessa persona / squadra / organizzazione. Di solito, questo non viene fatto mettendo IBlaster in un pacchetto separato su cui entrambi i moduli dipendono. Invece, IBlaster sarebbe parte di MasterPackage e introdurrai un modulo adattatore . Le dipendenze possono essere illustrate in questo modo:

L'adattatore dipende da entrambi i pacchetti, ma Master dipende solo da IBlaster . Tali adattatori si rivelano estremamente utili quando si scrivono i test di unità e si vuole prendere in giro il BlasterPackage . Ovviamente, MasterPackage richiede che sia fornito un adattatore conforme, ma non esiste una dipendenza concreta dal BlasterAdapter . Anche quando rendi tutte le dipendenze esplicite e configurabili, a un certo punto l'interfaccia utente e provider di interfaccia dovranno essere connessi (dipendenza iniezione ).