Matheus Tardivo

Thinking and talking about software development

Archive for outubro \31\UTC 2007

Don’t talk to strangers

Posted by Matheus Tardivo em outubro 31, 2007

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.

Anúncios

Posted in Java, padrões de projeto | 1 Comment »