A Lei de Demeter (LoD) ou princípio do menor conhecimento é uma diretriz para o desenvolvimento de software, particularmente em programas orientados a objeto. Em sua forma geral, a LoD é um caso específico de loose coupling ou acoplamento fraco. 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.

A noção fundamental é que um determinado objeto deve assumir o mínimo possível sobre a estrutura ou propriedades de qualquer outra coisa (incluindo seus subcomponentes), em conformidade com o princípio de "ocultar informações". Ele pode ser visto como um corolário do princípio do privilégio mínimo, o que determina que um módulo deve possuir apenas as informações e os recursos necessários para a sua finalidade legítima.

É assim chamado por sua origem na Projeto Demeter, uma programação adaptativa e uma programação orientada a aspectos. O projeto foi nomeado em honra de Deméter, "mãe-da-distribuição" e o deus grego  da agricultura, para significar uma filosofia bottom-up de programação que também é incorporada na própria lei.

Na programação orientada a objeto Quando aplicada a programas que utilizam orientação a objetos, a Lei de Deméter pode ser mais precisamente chamado de "Lei de Deméter, para as Funções/Métodos" (LoD-F). Neste caso, um objeto de A pode solicitar um serviço (chamar de um método) de uma instância de um objeto B, mas o objeto de A não deve "chegar através" do objeto B para aceder a outro objeto, C, para fazer requisições de seus serviços. Fazer isso significaria que o objeto de A implicitamente requer maior conhecimento da estrutura interna do objeto B . Em vez disso, a interface de  B deve ser modificada, se necessário, para que se diretamente pode servir os pedidos (requests) do objeto A , propagando para qualquer subcomponentes relevante. Como alternativa, A pode ter uma referência direta ao objeto C e efetuar pedido diretamente a ele. Se a lei for seguida, apenas objeto B , conhece a sua própria estrutura interna.

Mais formalmente, a Lei de Deméter, para funções que requerem um método m de um objeto O só podem invocar os métodos dos seguintes tipos de objetos:

O próprio Os parâmetros de m Quaisquer objetos criados/instanciado dentro de m O componente de objeto direto Uma variável global, acessível por S, no escopo do m

 Em particular, um objeto deve evitar invocar métodos de um objeto membro retornado por outro método. Para muitas linguagens modernas orientadas a objetos que usam um ponto como identificador de campo, a lei pode ser declarada simplesmente como "use apenas um ponto".  Isto é, o código de a.b.Método() quebra a lei, onde a.Método() não. Como uma analogia, quando se quer que um cão pare de caminhar, não se dá o comando para as pernas diretamente; em vez disso, dá-se o comanda ao cão que, em seguida, comanda as suas próprias pernas.

Vantagens A vantagem de seguir a Lei de Deméter é que o software resultante tende a ser mais manutenível e adaptável. Como os objetos são menos dependentes da estrutura interna de outros objetos, "containers" de objetos podem ser alterados sem reformulação de quem o chama.

Basili et al. publicado com os resultados experimentais, em 1996, sugerindo uma menor "Response For a Class" ( RFC, o número de métodos potencialmente invocados em resposta à chamada de um método dessa classe) pode reduzir a probabilidade de bugs. Seguindo a Lei de Deméter pode resultar em uma menor RFC. No entanto, os resultados também sugerem que um aumento no Weighted Methods per Class (WMC, o número de métodos definidos em cada classe) pode aumentar a probabilidade de bugs. A seguir a Lei de Deméter também pode resultar em um maior WMC; veja Desvantagens.

Uma arquitetura multicamadas pode ser considerada um mecanismo sistemático para implementar a Lei de Demeter em um sistema de software. Em uma arquitetura em camadas, o código dentro de cada camada só pode fazer chamadas para o código dentro da camada e codificar dentro da próxima camada abaixo. "Ignorar camadas" violaria a arquitetura em camadas.

Desvantagens Embora o LoD aumente a capacidade de adaptação de um sistema de software, ele pode (mas não necessariamente) resultar na necessidade de escrever muitos métodos de wrapper para propagar chamadas para componentes; Em alguns casos, isso pode adicionar mais tempo e espaço.

No nível do método, o LoD leva a interfaces estreitas, fornecendo acesso a tantas informações quantas forem necessárias para executar seu trabalho, já que cada método precisa conhecer um pequeno conjunto de métodos de objetos intimamente relacionados. Por outro lado, no nível de classe, o LoD leva a interfaces amplas (isto é, ampliadas), porque o LoD requer a introdução de muitos métodos auxiliares em vez de escavar diretamente nas estruturas de objetos . Uma solução para o problema de aumento da classe de interfaces é a abordagem aspect-oriented , onde o comportamento do método é especificado como um aspecto em um alto nível de abstração. Isso é feito por meio de um método adaptativo que encapsula o comportamento de uma operação em um local, com o qual o problema de espalhamento é resolvido. Ele também abstrai a estrutura de classes que resulta em evitar o problema de emaranhamento. As interfaces amplas são gerenciadas por meio de uma linguagem que especifica implementações. Tanto a estratégia de travessia quanto o visitante adaptativo usam apenas um conjunto mínimo de classes que participam da operação, e as informações sobre as conexões entre essas classes são abstraídas.

Desde quando o LoD exemplifica um tipo específico de acoplamento, e não especifica um método de endereçamento deste tipo de acoplamento, é mais adequado como uma métrica para o "code smell" em oposição a uma metodologia para a construção de sistemas emparelhados.

Ligações externas A lei de Demeter (LoD) "Programação Orientada a objeto: Um Objectivo Senso de Estilo" (OOPSLA '88 Processo) (PDF) The Paperboy, A Carteira,e A Lei De Demeter (PDF) Phil Haack: "A Lei de Deméter não é um Ponto de Contagem Exercício" Lieber: "Phil Holanda a Lei de Demeter" "Adaptativo Object-Oriented Software, Deméter Método"

Categoria:Programação orientada a objetos