Escolha entre “Dependency Inversion e Dependency“ Delegation ”para um terceiro módulo

5

Suponha que eu tenha MasterPackage contendo uma classe Master e BlasterPackage contendo a classe Blaster . Como Master precisa de um Blaster para funcionar, o nível mais alto MasterPackage depende diretamente do nível inferior BlasterPackage .

Usando a clássica Inversion Dependency Inversion, adicionaríamos IBlaster (ou AbstractBlaster ) a MasterPackage , assim, invertendo a dependência entre os pacotes.

Mas, enquanto enfrentava esse problema, percebi que poderia criar um pacote terceiro - vamos chamá-lo de MasterBlasterInterfaces - e colocar IBlaster lá. Isso "delegaria" a dependência para o terceiro pacote comum, e os dois pacotes originais seriam agora dissociados um do outro.

Mas, se eu tiver um pacote de nível mais alto chamado ThunderDome , ele terá que lidar diretamente com BlasterPackage , não seria? Eu sinto que isso meio que viola o encapsulamento, enquanto com dependência direta Master poderia abstrair a própria existência de Blaster .

Então a questão é:

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?

    
por heltonbiker 15.12.2015 / 13:06
fonte

1 resposta

2

Invertendo a dependência como você descreveu, tudo bem se você controlar o outro pacote e se essa dependência direta for aceitável. Para muitos softwares, isso é totalmente aceitável. Mas, obviamente, isso não funciona se o seu BlasterPackage for uma biblioteca externa na qual você confia.

A mágica de introduzir uma interface IBlaster é que MasterPackage e BlasterPackage podem trabalhar juntos sem ter um relacionamento de dependência direto e sem serem escritos pela mesma pessoa / equipe / organização. Geralmente, isso não é feito colocando IBlaster em um pacote separado do qual os dois módulos dependem. Em vez disso, IBlaster seria parte de MasterPackage e você introduziria um módulo adaptador . As dependências podem ser ilustradas assim:

O adaptador depende dos dois pacotes, mas o Master depende apenas de IBlaster . Esses adaptadores são extremamente úteis ao escrever testes de unidade e querem ridicularizar o BlasterPackage . Obviamente, o MasterPackage exigirá que algum adaptador em conformidade seja fornecido, mas não há dependência concreta do BlasterAdapter . Mesmo quando você torna todas as dependências explícitas e configuráveis, em algum momento os consumidores de interface e provedores de interface terão que estar conectados (dependência injeção ).

    
por 15.12.2015 / 15:44
fonte