Lei de Demeter
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 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 editar
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:[2]
Opróprio- Os parâmetros de
m - Quaisquer objetos criados/instanciado dentro de
m Ocomponente de objeto direto- Uma variável global, acessível por
S, no escopo dom
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 editar
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
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.
Referências
- ↑ Macedo, Emerson. «README.markdown: Demeter». GitHub. Consultado em 5 de julho de 2012
- ↑ «The Paperboy, The Wallet, and The Law Of Demeter» (PDF)
- ↑ «A Validation of Object-Oriented Design Metrics as Quality Indicators». IEEE Transactions on Software Engineering. 22. doi:10.1109/32.544352
- ↑ «Introducing Demeter and its Laws»
- ↑ «Tell, Don't Ask»
- ↑ 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
- ↑ «Aspect-oriented programming with adaptive methods» (PDF). Commun. ACM. 44. doi:10.1145/383845.383855[ligação inativa]
Ligações externas editar
- 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"