Acoplamento/coesão

Question

Embora existam muitos bons exemplos neste fórum que contêm exemplos de acoplamento e coesão, estou lutando para aplicá -lo completamente ao meu código. Posso identificar peças no meu código que podem precisar de alterar. Qualquer especialista em Java seria capaz de dar uma olhada no meu código e me explicar quais aspectos são bons e ruins. Eu não me importo de mudar isso sozinho. É que muitas pessoas parecem discordar entre si e estou achando difícil entender quais princípios seguir ...

Answer 1

Eu posso recomendar o livro de Alan e James Padrões de design explicados-uma nova perspectiva sobre o design orientado a objetos (ISBN-13: 978-0321247148):

É um ótimo livro sobre tem um e é um Decisões, incluindo coesão e acoplamento em design orientado a objetos.

Answer 2

Primeiro, gostaria de dizer que a principal razão pela qual você obtém respostas tão variadas é que isso realmente se torna uma arte ao longo do tempo. Muitas das opiniões que você obtém não se resumem a uma regra ou fato rápido, mais se resume à experiência geral. Depois de 10 a 20 anos fazendo isso, você começa a lembrar o que fez que causou dor e como você evitou fazê-las novamente. Muitas respostas funcionam para alguns problemas, mas é a experiência do indivíduo que determina sua opinião.

Na verdade, há apenas uma coisa realmente grande que eu mudaria no seu código. Eu consideraria investigar o que é chamado de padrão de comando. As informações sobre isso não devem ser difíceis de encontrar na web ou no livro do GoF.

A idéia principal é que cada um dos seus comandos "Adicionar filho", "Adicionar pai" se torne uma classe separada. A lógica para um único comando é anexado em uma única classe pequena e fácil de testar e modificar. Essa classe deve ser "executada" para fazer o trabalho da sua classe principal. Dessa forma, sua classe principal só precisa lidar com a análise da linha de comando e pode perder a maior parte do conhecimento de uma família. Ele só precisa saber quais mapas da linha de comando em quais classes de comando e chutá -los.

Esses são meus 2 centavos.

Answer 3

Resumidamente:

A coesão na engenharia de software, como na vida real, é o quanto os elementos consistindo um todo (no nosso caso, digamos uma aula) podem ser ditos que eles realmente pertencem juntos. Assim, é uma medida de quão fortemente relacionado cada peça de funcionalidade expressa pelo código -fonte de um módulo de software.

Uma maneira de olhar para a coesão em termos de OO é se os métodos da classe estão usando algum dos atributos privados.

Agora, a discussão é maior que isso, mas a alta coesão (ou o melhor tipo de coesão - a coesão funcional) é quando partes de um módulo são agrupadas porque todas contribuem para uma única tarefa bem definida do módulo.

O acoplamento em palavras simples é o quanto um componente (novamente, imagine uma classe, embora não necessariamente) conhece o funcionamento interno ou elementos internos de outro, ou seja, quanto conhecimento ele tem do outro componente.

O acoplamento solto é um método de interconectar os componentes em um sistema ou rede para que esses componentes dependam um do outro na menor extensão praticamente possível ...

Em muito tempo:

Eu escrevi um post sobre isso. Ele discute tudo isso com muitos detalhes, com exemplos etc. Também explica os benefícios de por que você deve seguir esses princípios. Eu acho que poderia ajudar ...

Answer 4

O acoplamento define o grau em que cada componente depende de outros componentes do sistema. Dados dois componentes A e B, quanto código em B deve mudar se A alterações. A coesão define a medida de quão coerentes ou fortemente relacionados são as várias funções de um único componente de software. Refere -se ao que a classe faz. A baixa coesão significaria que a classe faz uma grande variedade de ações e não se concentra no que deve fazer. A alta coesão significaria então que a classe está focada no que deveria estar fazendo, ou seja, apenas métodos relacionados à intenção da classe. Nota: Boas APIs exibem acoplamento frouxo e alta coesão. Uma forma particularmente abominável de acoplamento apertado que sempre deve ser evitado é ter dois componentes que dependem um do outro direta ou indiretamente, ou seja, um ciclo de dependência ou dependência circular. Informações detalhadas no link abaixohttp://softwarematerial.blogspot.sg/2015/12/coupling-and-cohesion.html