Lei de Demeter

Origem: Wikipédia, a enciclopédia livre.
Saltar para a navegação Saltar para a pesquisa

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:[1]

  • 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 de 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[editar | editar código-fonte]

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 , 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:[2]

  1. O próprio
  2. Os parâmetros de m
  3. Quaisquer objetos criados/instanciado dentro de m
  4. O componente de objeto direto
  5. 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 para caminhe, não se da o comando para as pernas diretamente; em vez disso, da o comanda ao cão que, em seguida, da o comando as suas próprias pernas.

Vantagens[editar | editar código-fonte]

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.[3] 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[editar | editar código-fonte]

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.[4][5]

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.[6] 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 ,[7] 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.

Veja também[editar | editar código-fonte]

Referências[editar | editar código-fonte]

  1. Macedo, Emerson. «README.markdown: Demeter». GitHub. Consultado em 5 de julho de 2012 
  2. «The Paperboy, The Wallet, and The Law Of Demeter» (PDF) 
  3. «A Validation of Object-Oriented Design Metrics as Quality Indicators». IEEE Transactions on Software Engineering. 22. doi:10.1109/32.544352 
  4. «Introducing Demeter and its Laws» 
  5. «Tell, Don't Ask» 
  6. Lieberherr, K.; Holland, I.; Riel, A. (1988). «Object-Oriented Programming: An Objective Sense of Style». Conference proceedings on Object-oriented programming systems, languages and applications (OOPSLA '88) (PDF). [S.l.: s.n.] doi:10.1145/62083.62113 
  7. «Aspect-oriented programming with adaptive methods» (PDF). Commun. ACM. 44. doi:10.1145/383845.383855 [ligação inativa]

Links externos[editar | editar código-fonte]