Entendendo a Lei de Demeter em Design de Software

O Que é a Lei de Deméter?
A Lei de Deméter, também conhecida como "Princípio do Mínimo Conhecimento", é uma diretriz de design de software formulada para promover o encapsulamento e reduzir o acoplamento entre classes.

A pauta foi proposta por Ian Holland na Northeastern University no final de 1987, e pode ser sucintamente resumido nas seguintes formas:

• Cada unidade deve ter conhecimento limitado sobre outras unidades: apenas unidades próximas se relacionam.
• Cada unidade deve apenas conversar com seus amigos; Não fale com estranhos.
• Apenas fale com seus amigos imediatos.

Em termos simples, ela recomenda que um objeto deve se comunicar apenas com seus amigos mais próximos e não se intrometer em detalhes internos de outros objetos.

Definição
A definição formal da Lei de Deméter pode ser resumida da seguinte forma:

Um método M de uma classe C deve apenas chamar métodos que pertencem a:

1. C (a própria classe),
2. Objetos criados por M,
3. Objetos passados como parâmetros para M,
4. Objetos armazenados em variáveis de instância de C.

Exemplo de Violação da Lei de Deméter
Considere o seguinte exemplo em Java, onde a Lei de Deméter é violada:

Problemas com Este Código
No código acima, a classe ProcessadorDePagamentos conhece muitos detalhes internos de Pedido, Cliente e Endereco, o que viola a Lei de Deméter. Isso resulta em alto acoplamento e baixa coesão, dificultando a manutenção e a evolução do sistema.

Exemplo de Conformidade com a Lei de Deméter
Agora, vamos refatorar o código para conformidade com a Lei de Deméter:

Melhorias com Este Código
No código refatorado, a classe ProcessadorDePagamentos só conhece Pedido e não precisa saber sobre a estrutura interna de Cliente ou Endereco. Isso reduz o acoplamento e melhora a coesão.

Vantagens

• Redução de Acoplamento: Minimiza a dependência entre classes, tornando o código mais modular e fácil de modificar.
• Maior Encapsulamento: Promove o encapsulamento, ocultando os detalhes internos das classes.
• Facilidade de Manutenção: Com menos dependências, as mudanças em uma classe têm menor probabilidade de impactar outras partes do sistema.
• Teste e Debugging Simplificados: Classes menos acopladas são mais fáceis de isolar e testar.

Desvantagens

• Aumento do Número de Métodos: Pode levar a um aumento no número de métodos pass-through, que simplesmente delegam chamadas a outros métodos.
• Complexidade Percebida: Em alguns casos, pode ser mais difícil entender o fluxo de chamadas, especialmente para novos desenvolvedores que ainda não estão familiarizados com a base de código.

Aplicação Prática da Lei de Deméter
Para aplicar a Lei de Deméter de maneira eficaz, siga estas práticas:

• Utilize Métodos de Acesso Adequados: Em vez de expor estruturas internas, forneça métodos que retornem as informações necessárias.
• Delegue Responsabilidades: Cada classe deve ser responsável por suas próprias operações e não delegar trabalho a objetos internos de outras classes.
• Revise Regularmente o Código: Realize revisões de código focadas na conformidade com a Lei de Deméter para garantir que novas violações não sejam introduzidas.

Conclusão
A Lei de Deméter promove um design de software mais limpo e sustentável ao reduzir o acoplamento entre classes e aumentar o encapsulamento. Aplicar este princípio pode parecer trabalhoso no início, mas os benefícios a longo prazo em termos de manutenibilidade e clareza do código são inegáveis.