Inversão de Dependência e Desacoplamento

5

Gostaria de saber se alguém pode explicar o último parágrafo escrito neste exemplo em Dependency Inversion & Dissociação.

link

Seguindo o código de exemplo, entender bem o raciocínio por trás do desacoplamento de classes pela implementação de uma classe base é bom.

O que eu gostaria de esclarecer é o último parágrafo:

However, there is one problem with this implementation. We don’t have a main method. We > definitely need one in order to run our application, and somewhere in this main method we will need to instantiate the LocalVoteRecorder.

By instantiating the LocalVoteRecorder in our main method, we would break Rule #1 of Dependency Inversion. We have coded to the abstraction, we have integrated our changes, but our application would still have a dependency on a lower level class.

Isso significa que não é possível criar um aplicativo realmente desacoplado? Como é possível escrever um aplicativo 100% desacoplado? É necessário, e existe alguma prática recomendada que eu possa ler?

Muito obrigado

    
por Jnanathan 12.01.2015 / 12:19
fonte

4 respostas

3

É muito difícil (embora em uma linguagem que tenha reflexão não totalmente impossível) criar um aplicativo 100% desacoplado. Com a reflexão, podemos usar isso para permitir que o usuário especifique classes concretas para cada objeto necessário no aplicativo em tempo de execução (talvez por meio de um arquivo de configuração), obtendo assim um desacoplamento completo em detrimento do aumento da complexidade.

Mas uma pergunta mais importante a fazer é por que você gostaria de fazer isso.

Tentamos diminuir o acoplamento na maior parte do nosso código porque o acoplamento torna a alteração mais difícil, fazendo com que uma única alteração tenha consequências para todo o código acoplado ao módulo que foi alterado.

Mas se agruparmos todos os acoplamentos em um único local, esse problema será atenuado. Uma alteração no comportamento de um módulo também pode exigir uma alteração no código que inicializa o módulo, mas como todo esse código é mantido em conjunto, nenhuma outra alteração se propaga desse código de inicialização, portanto, não experimentamos os efeitos negativos. Isso é bom o suficiente para quase todas as aplicações.

    
por 12.01.2015 / 13:34
fonte
2

Classificar de. Você não pode evitar o acoplamento completamente. O melhor que você pode fazer é trocar um tipo de acoplamento por um tipo geralmente mais desejável. Em vez de dois objetos concretos acoplados uns aos outros, cada um deles é acoplado a uma interface abstrata.

Além disso, você precisa depender de uma implementação concreta em algum ponto. Só porque essas dependências não são resolvidas até que o tempo de execução não signifique que elas não existem. Às vezes, o programador não se importa com qual implementação concreta é usada, mas geralmente eles precisam de uma maneira de especificá-lo de alguma forma, o que significa um arquivo de configuração.

Então, enquanto você pode ter um programa sem nenhuma dependência concreta em tempo de compilação, geralmente não vale a pena, a menos que você tenha alguma necessidade específica de substituir classes específicas em tempo de execução.

    
por 12.01.2015 / 19:42
fonte
1

O acoplamento apertado é ruim. O acoplamento frouxo é o que precisa. E nada funciona em isolamento completo, então a dependência (para interface) é inevitável.

As melhores práticas são criar componentes desacoplados conforme descrito aqui para evitar as desvantagens do aplicativo strongmente acoplado, como mencionado em esta página da Wikipedia . Considere as linhas abaixo também como elas foram aqui :

A module is closed if it has a well defined stable interface that all other modules must use and that limits the interaction and potential errors that can be introduced into one module by changes in another.

Obrigado.

    
por 12.01.2015 / 13:04
fonte
1

I'm wondering if someone might explain the last paragraph:

O autor diz que ter "Dependency Inversion & Decoupling" por si só não é suficiente.

Ele significa que "ligar a aplicação" implementando um método "principal" que constrói todas as classes é uma opção que você usa os "módulos independentes"

No próximo capítulo, ele apresenta como tornar a "fiação da aplicação por código" muito mais fácil, introduzindo "Injeção de Dependência"

E depois ele apresenta o spring-ioc que pode fazer a maior parte do wirining para você.

Does this mean it is not possible to create a truly decoupled application?

Não mas um ioc como a primavera pode tornar muito mais fácil se você entendeu os princípios por trás.

    
por 12.01.2015 / 20:15
fonte