Kenneth Freitas

E para finalizar nosso papo sobre “Coupling, o inimigo em comum” vamos falar de coesão, claro! Coesão são as partes que devem ser contidas no mesmo módulo, ou seja, um acoplamento que faz sentido. Funcionalidades parecidas e que se complementam devem estar próximas umas das outras. Tenha em mente que sempre que separamos um módulo com coesão, estamos aumentando o acoplamento. Com isso vamos dar uma olhada nos tipos de coesão que existem: Functional Cohesion Quando todas as partes do módulo se relacionam fazendo com que o módulo tenha tudo para funcionar. Sequential Cohesion Quando dois módulos interagem de maneira que o output de um vira o input do outro. Communicational Cohesion Quando dois módulos operaram juntos para criar um output. Procedural Cohesion Quando dois módulos devem ser executados em uma ordem específica. Temporal Cohesion Quando módulos trabalham juntos de forma temporária para servir um outro módulo. Logical Cohesion Quando módulos compartilham uma lógica de operação...

Continuando a série de “Coupling, o inimigo em comum” , agora que sabemos os tipos de coupling, está na hora de analisar os níveis de quanto eles estão engessando sua aplicação, começando dos mais fortes para os mais fracos. Pathological coupling A pior situação possível, é quando um componente depende de um funcionamento interno de outro componente, seja estaticamente ou temporalmente. Por exemplo, temos uma classe utilizando uma implementação concreta de outra classe ao invés de uma abstração, ou pior, parte dela, ou seja, qualquer mudança afetará diretamente essas classes. External coupling É quando seus componentes utilizam de formatos ou protocolos impostos por agentes externos. Bora pro exemplo: a velha discussão de colocar a “lógica” na controller. A partir do momento que você está fazendo isso, se você tem uma API Rest, automaticamente todos seus componentes estão limitados a aceitar apenas nesse formato. Caso algum dia alguém chegar usando gRPC ou qualquer outro protocolo/form...

Não importa o modelo arquitetural super maravilhoso que você implementou, ou quão lindo seja seu código, coupling sempre irá existir e uma hora ou outra vai te dar aquela dor de cabeça na manutenção do seu sistema. Então, bora analisar nossa estrutura para encontrar pontos de atenção o quanto antes. Um jeito (sendo o mais óbvio) para realizar essa análise, é claro, olhando o código-fonte da aplicação. Mas podemos (e devemos) nos afastar um pouco desta visão “micro”, até porque uma análise precisa no código é bem difícil de ser realizada. Ter uma visão do todo realmente faz a diferença para identificar componentes e elementos na nossa aplicação. Temos três principais alvos a serem identificados em nossa arquitetura, são eles: Static coupling, Temporal coupling e Component size. Static Coupling Em static temos duas distinções "afferent coupling”, quando vários componentes dependem de algum em específico. E “efferent coupling”, que é o contrário, quais ...