A Lei de Deméter ou o Princípio do Mínimo Conhecimento nos orienta a reduzir as interações entre objetos, limitando-as a apenas alguns “amigos” mais próximos.
No projeto de um sistema, você deve tomar cuidado com o número de classes com que qualquer objeto interage e também com a forma como essa interação ocorre.
Este princípio nos orienta a não criar projetos com um grande número de classes interconectadas, o que faz com que qualquer alteração numa parte do sistema exerça um efeito em cascata sobre outras partes. Um sistema com muitas dependências entre múltiplas classes é um sistema frágil, de difícil manutanção e complexo demais para ser compreendido por outros.
O princípio nos fornece algumas dicas: pegamos um objeto qualquer e, a partir de qualquer método nesse objeto, só podemos invocar métodos quer pertençam:
- Ao próprio objeto
- A objetos que tenham sido passados como parâmetro para o método
- A qualquer objeto que seja criado ou instanciado pelo método
- A quaisquer componentes do objeto - Pense em “componente” como qualquer objeto que seja referenciado por uma variável de instância. Em outras palavras, esta seria uma relação TEM-UM.
Um exemplo:
Sem o princípio:
public float getTemp() {
Thermometer thermometer = station.getThermometer();
return thermometer.getTemperature();
}
Com o princípio:
public float getTemp() {
return station.getTemperature();
}
Em um outro exemplo:
String nomeFilial = funconario.getDepartamento().getFilial().getNome();
Caso você tenha que navegar muito nos seus objetos você está, provavelmente, com um problema na sua modelagem. Neste caso, talvez o que você teria que fazer seria delegar isso para uma classe de “meio de campo”.
O uso de Padrões de Projeto e outros Princípios OO ajudam na aplicação da Lei de Deméter.
Já que comentei sobre Padrões de Projeto e outros Princípios OO, vou listar abaixo alguns desses princípios:
- Encapsule o que varia
- Dê prioridade à composição em relação à herança
- Programe para interface, não para implementações - Estratégia
- Tente manter conexões flexíveis entre objetos que interagem.
- As classes devem estar abertas para a extensão, mas fechadas para modificação.
E alguns padrões:
Claro que existem outros padrões que podem auxiliá-lo e, por isso, recomendo a leitura de livros sobre o assunto.
A Lei de Deméter é uma Rule of thumb e seu uso deve ser priorizado, mas, por diversos motivos, nem sempre podemos utilizá-la.
Embora o Princípio do Mínimo Conhecimento reduza as dependências entre objetos, e estudos tenham comprovado que isso simplifica a manutenção do software, sua aplicação também exige que mais classes “envelopadoras” sejam escritas para lidar com as chamadas de métodos em outros componentes. Isso pode aumentar a complexidade e o tempo de desenvolvimento do software, além de reduzir seu desempenho durante a execução.
Uma boa parte desse texto foi retirado do livro Head First Design Patterns que, com certeza, é uma ótima leitura.