[Arquitetura] Coupling, o inimigo em comum - Parte 1

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 são os componentes que algum em específico depende.

Temporal Coupling

Esse é um dos mais difíceis de identificar e um dos grandes causadores de “quebra” do sistema quando acontece alguma alteração. Temporal Coupling acontece normalmente quando temos um “orquestrador”, por exemplo: Componente A irá realizar uma transação, e nele vamos utilizar Componente B e C, mesmo que B e C não fazem ideia de que um ou outro existem, na transação de A eles vão estar temporariamente acoplados, pois A necessita utilizá-los de maneira conjunta.

Component Size

Esse é o mais fácil de identificar, quando temos um componente grande demais, muito provavelmente ele está matando alguns princípios e escopos, uma maneira de verificar isso é analisando o número de classes, interfaces (e outros tipos em geral) que estão nesse componente/módulo e também ver o número de linhas de código (as famosas classes god). Mas por que disso? Normalmente quando temos componentes muito grandes a chance deles estarem realizando os outros tipos de coupling dentro dele são muito altas e a técnica mais simples para reduzir o coupling é fazer o split dos componentes deixando-os menores.

Independente do modelo arquitetural que está seguindo ou paradigma, coupling é uma realidade no sistema, por isso saber identificá-los assim como reduzi-los é essencial para qualquer projeto. Técnicas como injeção de dependência e princípios como LSP e DIP são essenciais para conseguir manter as “bilidades” da sua arquitetura. Abraços!