Como posso saber se o software é altamente acoplado?

Estou familiarizado com o termo "altamente acoplado", mas estou curioso para saber se existem sinais (odores de código) que podem indicar que o código está altamente acoplado. Atualmente, estou trabalhando com Java EE, mas isso pode se aplicar a qualquer idioma.

Editar:

Caso alguém esteja interessado, este artigo parece útil: Em busca da qualidade do código: Cuidado com o casal apertado! (IBM)

O indicador número um de módulos mal acoplados, na minha opinião, são dependências bilaterais. Por exemplo, o Módulo1 chama alguma função no Módulo2 e o Módulo2 chama alguma função no Módulo1.

A maioria das interfaces deve ser unidirecional. Se o módulo chamado precisar passar algumas informações para o módulo de chamada que não é retornado como parte da chamada, ele deve usar algum tipo de passagem de mensagem ou mecanismo de acionamento de evento, como uma fila de mensagens. Idealmente, o identificador para a interface de passagem de mensagens deve ser passado durante algum processo de inicialização ou registro. Isso abstrai completamente a interface de tal maneira que o módulo não se importa com quem é o evento ... portanto, é dissociado.

Outra indicação é quando um módulo está constantemente chamando outro módulo para algum conjunto de dados específico. Isso deve fazer você questionar quem realmente deve ser o proprietário do conjunto de dados. Por que este módulo em questão sempre precisa ver dados que pertencem a algum outro módulo?

Uma terceira ferramenta, por assim dizer, é perguntar a si mesmo: "Posso retirar este módulo e substituí-lo sem exigir alterações em outros módulos.

Esta não é de forma alguma uma lista exaustiva, mas são as três principais coisas que me pergunto ao projetar software.

O antigo ditado de design é: "Você pode tocar seus amigos e seus amigos. Mas você não pode tocar seus amigos." Isso é acoplamento em poucas palavras.

Sinais de código altamente acoplado incluem interfaces muito grandes que permitem que as pessoas saibam detalhes particulares da implementação e objetos que parecem "saber muito um do outro". Existem ferramentas para análise automática que sinalizarão códigos que parecem fortemente acoplados a você. Consulte http://www.scitools.com/features/metricsintro.php para obter uma aleatória. (Não tenho ideia de como funciona. Ele apareceu bastante alto em uma pesquisa no Google.)

Tente escrever alguns testes de unidade para as aulas. Se você não pode testar facilmente as classes sem a necessidade de criar / simular cargas de classes de suporte ou de um db / ui, então é um sinal claro de um acoplamento / dependências ruins.

É também uma das melhores curas, mas você precisa fazer isso durante a codificação (como TDD) para ser honesto.

O sinal óbvio para mim é que tudo é público.

O outro sinal são as violações da Lei de Deméter - referências excessivas a this.SomeObj.SomeProp.SomeProp em interfaces não fluentes.

Certa vez, vi o que chamei de "classe puppetmaster" que construiu um formulário de entrada de dados on-the-fly. Havia várias outras violações de design de software, pelo que o acoplamento excessivo era a menor das suas preocupações.

Ao recuperar dados dos controles que criou, fez o seguinte:

var control = activeDataEntryControl as CustomTextBox;
if (control != null)
   result = control.NestedTextBox.Text;

/* several other controls */

O efeito cascata .

Toda mudança tem um efeito cascata em todos os módulos fortemente acoplados.

O princípio "Aberto-Fechado" foi violado por não estar devidamente fechado e a mudança vazar.

Verifique o número de # include / imports etc entre classes / packages / dlls / jars / whatnots. Tente desenhar um gráfico disso, mentalmente, manualmente ou usando algum tipo de ferramenta.

• Se esse gráfico for denso (ou seja, muitas conexões em todo o lugar), seu sistema é monolítico e altamente acoplado.
• Se estiver claramente dividido em camadas, sem conexões nas / através das camadas, e as conexões forem poucas, você terá um sistema modular e dissociado.

Se você acha impossível implementar um recurso porque não tem ideia de onde uma responsabilidade específica se aplica, seu sistema está muito acoplado.

Para sinais muito básicos, considere procurar o número de interfaces e seu uso entre classes de pacotes diferentes (o código geralmente fracamente acoplado contém interfaces e há uma interação direta limitada entre as classes individuais em pacotes diferentes), número de nomes de classes que podem ser usado para agrupar outras classes (no código fracamente acoplado, a interação real entre classes que têm tarefas diferentes é feita por funções de interface ou por funções de classes mais comuns / de agrupamento) ou numerar variáveis ​​públicas dentro de classes (variáveis ​​mais fracas, menores ou até mesmo inexistentes) )

Praticamente todos os odores de código indicam acoplamento supérfluo de alguma maneira. Suponho que o cheiro que mais indica acoplamento possa ser "Intimidade Inadequada" (meu cheiro favorito).

Suponho que outro método razoável de medir seria contar as linhas no seu diagrama UML. Se você tiver N objetos e N ^ N (ou mais) linhas entre eles, seu código será praticamente o máximo possível. N linhas provavelmente seriam o mínimo possível.