Como comentei antes, métricas de código são aliadas de um arquiteto. Basta ter em mente que, apenas utilizando LOC e CC, já podemos “ouvir” muita coisa que nosso (pobre) código tenta nos dizer.
Quando participamos de discussões sobre design é quase certo que ouviremos expressões como “acoplamento fraco” ou “acoplamento forte”. O acoplamento entre classes ou subsistemas é uma medida da interconexão entre essas classes ou subsistemas. Sendo assim, acoplamento forte significa que as classes relacionadas precisam conhecer detalhes internos umas das outras, as alterações se propagam pelo sistema, e o sistema é potencialmente mais difícil de entender.
Em suma, as metas por trás da obtenção de um acoplamento fraco entre classes e módulos são:
- Tornar o código mais fácil de ler;
- Tornar nossas classes mais simples para o consumo de outros desenvolvedores, ocultando a parte feia” do funcionamento interno em APIs bem projetadas;
- Isolar possíveis alterações em uma área pequena do código;
- Reutilizar classes em contextos completamente novos.
Acredite, todos falam em redução de acoplamento
A Lei de Demeter é um princípio básico do design. A definição resumida é: fale somente com seus amigos mais próximos (é um alerta quanto a possíveis riscos presentes no código com relação a dependência). Assim como a Lei de Demeter, uma boa quantidade de princípios, práticas e orientações endereçam soluções para diminuir o acoplamento, veja:
- Tell, Don’t Ask;
- Command/Query Separation;
- Feature Envy;
- Shotgun Surgery;
- Say It Once and Only Once;
- IoC;
- Dependency Injection;
- … e muito mais!
Pensando em acoplamento como uma métrica de código, veremos a seguir 2 exemplos importantíssimos.
Afferent / efferent Coupling (Ca e Ce, ou acoplamento aferente / eferente)
Como mencionado nos posts anteriores, não existe muito sentido em ficar extraindo manualmente qualquer tipo de métrica de software. Métricas devem ser baratas e capazes de serem extraídas rapidamente (com apoio de ferramentas).
Isso posto, temos que:
O acoplamento aferente (Ca) representa a contagem de quantas classes diferentes referem-se à classe atual, por meio de campos ou parâmetros
Por outro lado:
O acoplamento eferente (Ce) representa a contagem de quantas classes diferentes a classe atual faz referência, por meio de campos ou parâmetros
Quando pensamos em métricas relacionadas a acoplamento, começamos a perceber a necessidade de expressá-las visualmente. Observe no grafo abaixo o resultado da análise do acoplamento existente entre as classes: A, B, C, D, E, F, G e H.
Pegando a classe D como referência e destacando a métrica Ca, teríamos:
Mas se destacássemos a métrica Ce, tomando como base a mesma class D, obteríamos:
Outras leituras interessantes poderiam ser rapidamente retiradas do grafo, como por exemplo, o relacionamento cíclico existente entre as classes A, G e H.
Note que Ce e Ca podem mostrar, rapidamente, indícios de um design “mal cheiroso”. Essas métricas também servem para avaliarmos se regras de comunicação entre assemblies (definidas para um projeto) foram quebradas.
Até aqui…
Com as quatro métricas vistas até agora (LOC, CC, Ce e Ca), diversas informações interessantes podem ser extraídas do seu código fonte. No próximo post, veremos como combinar essas métricas para criarmos medidas de qualidade. Até lá! 😉
Excelente post sobre métricas Leandro, bastante claro e objetivo.
Minha dissertação de mestrado foi sobre a utilização de métricas de código e design para predição de defeitos. Pude observar que métricas de tamanho, complexidade e acoplamento de uma classe apresentam forte correlação com o número de defeitos detectados na mesma. Percebe-se então um grande potencial da utilização destas métricas para identificar classes mais propensas a defeitos, permitindo direcionar atividades de qualidade como inspeção, testes e refatoração nos pontos mais necessários. Isso é otimizar esforço humano, é agile!
Mais informações sobre isso no meu blog:
https//workingsweng.wordpress.com/
Abs!
Muito significativa a sua colaboração Gabriel, obrigado!
Tomei a liberdade de destacar o link direto para sua dissertação:
http://workingsweng.files.wordpress.com/2012/01/early_fix_frameworkpredicaomanutencaocorretivasoftwaremetricasproduto_gabrielmoreira.pdf
Abraços,
Leandro Daniel
Grande Leandro, parabéns pelo artigo!
As técnicas apresentadas e os excelentes gráfiocos explicativos mencionam bastante classes como artefato. Na sua opinião esta visão de fina granularidade de acoplamento também poderia ser usada na visão de componentes?
Existe alguma técnica mais específica para componentes?
Um abraço,
Vinicius
Grande mestre Senger! Caramba, agora me senti prestigiado! 🙂
O meu próximo post da série tratará especificamente desse assunto. Utilizarei as métricas apresentadas até agora para compor uma medida de qualidade. Aproveitando a sua dúvida, direcionarei para qualidade de assemblies.
Abraços,
Leandro Daniel
Estes grafos foram gerados por alguma ferramenta de analise de metricas ou foi desenhado por você mesmo em alguma ferramenta ?
Olá Kleiton,
Nos exemplos desenhei para ilustrar de forma mais abstrata, mas o NDepend é capaz de ler todo o código da sua solution e montar grafos deste tipo:
http://www.ndepend.com/
Abs,
Leandro Daniel