Eu deveria estar mais preocupado com o acoplamento entre pacotes ou entre unidades de distribuição?

Question

Eu tenho estado a olhar para métricas para acoplamento e também olhar para DSM .

Uma das ferramentas que eu tenho usado olha para o acoplamento entre 'módulos' com um módulo de ser uma unidade de distribuição (neste caso, um .NET assembly).

Eu sinto que eu deveria ser mais interessado em olhar para o acoplamento entre pacotes (ou namespaces) do que com unidades de distribuição.

Eu deveria estar mais preocupado com o acoplamento entre pacotes / namespaces (garantir que abstrações depende apenas abstrações, tipos concretos dependem abstrações e sua há ciclos nas dependências para que refactoring e estendendo é fácil) ou devo estar preocupado com se eu posso implantar novas versões sem a necessidade de atualizar as unidades inalterados de distribuição?

O que ninguém medir?

Por que vale a pena, a minha intuição é que, se eu focar no pacote / namespace acoplamento em seguida, a unidade de acoplamento distribuição virá de graça ou pelo menos ser mais fácil.

Answer 1

Primeiro, é fácil ir ao mar olhando para as dependências e acoplamento. Certifique-se de que você não está mais complica-lo.

Com esse aviso fora do caminho, aqui está o que eu sugiro.

Há realmente 3 pontos de vista diferentes para dependência / gestão de acoplamento: 1) estrutura física (isto é, dependências de montagem) 2) estrutura lógica (isto é, espaço de nomes dependências) 3) estrutura de execução (isto é, dependências de classes)

Para grandes apps, você vai precisar de pelo menos examinar todos os 3, mas você pode geralmente priorizar.

Para clientes aplicativos implantados, número 1 pode ser muito importante (ou seja, para coisas como plug-ins). Para aplicativos implantados dentro da empresa (ou seja, asp.net), item 1 geralmente acaba por não ser tão importante (excluindo estruturas reutilizados em vários apps). Geralmente, é possível implantar o aplicativo inteiro fácil o suficiente para não tomar a sobrecarga de uma estrutura complicada para # 1.

Item # 2 tende a ser mais uma questão de manutenção. Conheça os seus limites de camada e sua relação com namespaces (ou seja, você está fazendo uma camada por namespace ou você está embalados de forma diferente no nível lógico). Às vezes, as ferramentas podem ajudá-lo a fazer valer os seus limites camada de olhar para a estrutura de dependência lógica.

Item # 3 é realmente sobre fazer um bom design de classe. Todo bom desenvolvedor deve colocar diante de uma quantidade muito boa de esforço para assegurar que ele só está a assumir as dependências adequadas em suas aulas. Isto é mais fácil dizer do que fazer, e é tipicamente uma habilidade que tem de ser adquirido ao longo do tempo.

Para ficar um pouco mais perto do coração da sua pergunta, item 1 é realmente sobre como os projetos são definidos na solução VS. Portanto, este não é um item de medir. É mais algo que você configurar no início e deixar correr. Item # 2 é algo que você pode usar uma ferramenta para verificar durante constrói para ver se os desenvolvedores tenham quebrado nenhuma regra. É mais de uma verificação do que uma medida realmente. Item # 3 é realmente o que você gostaria de dar uma boa olhada na medição. Encontrar as classes em sua base de código que têm uma quantidade elevada de acoplamento vão ser pontos de dor na estrada, garantir a qualidade sobre esses caras. Além disso, medindo a este nível permite que você tenha alguns insights sobre a qualidade (geral) da base de código como ele evoluiu. Além disso, ele pode lhe dar uma bandeira vermelha se alguém verifica algum código realmente atrevido em sua base de código.

Então, se você quer priorizar, dar uma olhada rápida na posição # 1 e # 2. Sabem o que deve ser parecida. Mas para a maioria dos aplicativos, item 3 deve ser tomada o mais tempo.

Esta resposta, claro, exclui os quadros enormes (como o .NET BCL). Esses bebês precisam de muita atenção para o # 1. : -)

Caso contrário, você acabar com problemas como este: "As versões atuais do .NET Framework incluem uma variedade de bibliotecas baseadas em GUI que não iria funcionar corretamente no Server Core" http://www.winsupersite.com/showcase/win2008_ntk.asp

Onde você não pode executar .NET em um GUI-less instalação do Windows Server 2008 porque a estrutura leva dependências na GUI bibliotecas ...

Uma coisa final. Certifique-se de que você está familiarizado com os princípios por trás da boa gestão dependência / acoplamento. Você pode encontrar uma boa lista aqui:

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Answer 2

acoplamento e dependência ciclos entre as unidades de distribuição é mais "fatal" porque pode torná-lo realmente difícil de implementar seu programa -. E às vezes ela também pode torná-lo realmente difícil até mesmo compilar seu programa

você é mais do que certo, um bom design de nível superior que divide o código em pacotes lógicos e dependências claros e pré-definidos só vai chegar a maior parte do caminho, a única coisa que falta é a separação correta dos pacotes em unidades de distribuições.