Entendendo a Lei de Demeter em Design de Software
Tags: java, designpatterns, designsystem, oop
Published: 2024-05-28 21:17:31

**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:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mlnugo9eplep8yryzo1d.png)

**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:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hv482eksyaakfxd5cxor.png)

**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.