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

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/formato, bem, já sabe o que vai acontecer.

Control coupling

Acontece quando um componente ordena o que outro componente irá fazer, por exemplo: Temos um componente A que age como um repositório onde o componente B irá passar para ele X informações com uma flag “save”. Então, o componente A, com base na flag, irá efetuar a persistência, assim então B controlando A. 

Data coupling

Chegamos no mais fraco e também um dos mais comuns, que é quando vários componentes estão vinculados a um mesmo contexto de dados compartilhados, por exemplo, seu banco de dados. Se o componente A salva e o componente B realiza queries, caso componente A comece a salvar mais ou menos itens, implicará diretamente em B.

Como podemos analisar, vários desses tipos nos mais diferentes níveis existem em nossas aplicações, já dando ou só esperando para dar aquela dor de cabeça na próxima refatoração. Analisando como cada nível se comporta, já podemos pensar em uma solução bem simples para diminuí-los, que é criando camadas e mais camadas de abstrações. Em contrapartida, isto traz mais complexidade para aplicação e impacta diretamente o tempo de desenvolvimento. Com isso, sempre fica em mente o trade-off e até onde consegue ser evitado ou contornado. Falou!