Alta coesão, diz que cada classe deve possuir uma única responsabilidade. Desse modo ela se torna mais entendível e reutilizável. Maneiras de ter classes pequenas e reutilizáveis, e mantê-las Fechadas para Alterações e Abertas para Extensão, assim plugamos comportamentos a um objeto quando necessário, mantendo a classe base sempre enxuta.
Mas as vezes, mesmo essa única responsabilidade pode ser quebrada em responsabilidades menores ainda, tornando sua interface mais amigável.
Princípios como “Tell, Dont Ask”, mantêm nossas classes com baixo acoplamento e alta coesão.
O Problema
Classes com baixa coesão geralmente apresentação características mais de uma responsabilidade, com tamanho grande e pouca legibilidade. Essas classes são altamente sensíveis a mudanças e ferem diretamente os princípios Fechado para Mudanças mas Aberto para Extensões e Responsabilidade Única.
A Baixa coesão pode ser bem explícita ou nem tanto. Vamos a alguns exemplos.
Nossa classe conta bancária, claramente possuem muitas responsabilidades, como autenticação, controle de saldo, envio de email, e impressão. Apesar de todas essas responsabilidades estarem no contexto de ContaBancaria, elas não se correlacionam e deveria estar separadas em classes diferentes.
Caso seja necessário alterar o método de autenticação podem causar side effects em dependências que usam apenas depósito e retirada. Pois está tudo no mesmo lugar e uma dependência de depósito por consequência também é uma dependência de autenticar, violando o encapsulamento, a segregação de interfaces, e a substituição de liskov.
Agora um exemplo mais sutil.
Fizemos uma refatoração e removemos as responsabilidade de ContaBancaria e uma das novas classes extraídas foi a Extrato. Nelas agora está a responsabilidade de emitir extrato.
Mas note que a classe ainda possui duas responsabilidades, imprimir e enviar emails. Caso você mude o servidor de email, vai precisar revalidar a impressão, e caso você mude a impressão, vai precisar revalidar o envio de e-mails.
Aplicando a Alta Coesão
Fazendo mais uma refatoração, podemos extrair a Interface Extrato e criar as classes Concretas ExtratoPorEmail e ExtratoImpresso.
Agora com as classes ExtratoImpresso bem coesas, legíveis de melhor manutenção e isoladas. Caso seja necessário alterar o envio de email, o extrato impresso não será afetado nem suas dependências.
Conclusão
Com classes menores, fica menos custoso alterar, testar e manter seu código, reduzindo o risco de side effects.
Alguns princípios nos ajudam a manter a alta coesão como: Responsabilidade Única, Segregação de Interfaces, Substituição de LiskoveTell, Don´t Ask.