b'\n_START_ARTICLE_\nLei de Demeter\n_START_SECTION_\nVantagens\n_START_PARAGRAPH_\nA vantagem de seguir a Lei de Dem\xc3\xa9ter \xc3\xa9 que o software resultante tende a ser mais manuten\xc3\xadvel\xc2\xa0e adapt\xc3\xa1vel. Como os objetos s\xc3\xa3o menos dependentes da estrutura interna de outros objetos, "containers" de objetos podem ser alterados sem reformula\xc3\xa7\xc3\xa3o de quem o chama._NEWLINE_Basili et al. publicado com os resultados experimentais, em 1996, sugerindo uma menor "Response For a Class" (_NEWLINE_RFC, o n\xc3\xbamero de m\xc3\xa9todos potencialmente invocados em resposta \xc3\xa0 chamada de um m\xc3\xa9todo dessa classe) pode reduzir a probabilidade de bugs. Seguindo a Lei de Dem\xc3\xa9ter pode resultar em uma menor RFC. No entanto, os resultados tamb\xc3\xa9m sugerem que um aumento no Weighted Methods per Class\xc2\xa0(WMC, o n\xc3\xbamero de m\xc3\xa9todos definidos em cada classe) pode aumentar a probabilidade de bugs. A seguir a Lei de Dem\xc3\xa9ter tamb\xc3\xa9m pode resultar em um maior WMC; veja Desvantagens._NEWLINE_Uma arquitetura multicamadas\xc2\xa0pode ser considerada um mecanismo sistem\xc3\xa1tico para implementar a Lei de Demeter em um sistema de software. Em uma arquitetura em camadas, o c\xc3\xb3digo dentro de cada camada s\xc3\xb3 pode fazer chamadas para o c\xc3\xb3digo dentro da camada e codificar dentro da pr\xc3\xb3xima camada abaixo. "Ignorar camadas" violaria a arquitetura em camadas.\n_START_SECTION_\nDesvantagens\n_START_PARAGRAPH_\nEmbora o LoD aumente a capacidade de adapta\xc3\xa7\xc3\xa3o de um sistema de software, ele pode (mas n\xc3\xa3o necessariamente) resultar na necessidade de escrever muitos m\xc3\xa9todos de wrapper para propagar chamadas para componentes; Em alguns casos, isso pode adicionar mais tempo e espa\xc3\xa7o._NEWLINE_No n\xc3\xadvel do m\xc3\xa9todo, o LoD leva a interfaces estreitas, fornecendo acesso a tantas informa\xc3\xa7\xc3\xb5es quantas forem necess\xc3\xa1rias para executar seu trabalho, j\xc3\xa1 que cada m\xc3\xa9todo precisa conhecer um pequeno conjunto de m\xc3\xa9todos de objetos intimamente relacionados. Por outro lado, no n\xc3\xadvel de classe, o LoD leva a interfaces amplas (isto \xc3\xa9, ampliadas), porque o LoD requer a introdu\xc3\xa7\xc3\xa3o de muitos m\xc3\xa9todos auxiliares em vez de escavar diretamente nas estruturas de objetos\xc2\xa0. Uma solu\xc3\xa7\xc3\xa3o para o problema de aumento da classe de interfaces \xc3\xa9 a abordagem\xc2\xa0aspect-oriented\xc2\xa0,\xc2\xa0onde o comportamento do m\xc3\xa9todo \xc3\xa9 especificado como um aspecto em um alto n\xc3\xadvel de abstra\xc3\xa7\xc3\xa3o. Isso \xc3\xa9 feito por meio de um m\xc3\xa9todo adaptativo que encapsula o comportamento de uma opera\xc3\xa7\xc3\xa3o em um local, com o qual o problema de espalhamento \xc3\xa9 resolvido. Ele tamb\xc3\xa9m abstrai a estrutura de classes que resulta em evitar o problema de emaranhamento. As interfaces amplas s\xc3\xa3o gerenciadas por meio de uma linguagem que especifica implementa\xc3\xa7\xc3\xb5es. Tanto a estrat\xc3\xa9gia de travessia quanto o visitante adaptativo usam apenas um conjunto m\xc3\xadnimo de classes que participam da opera\xc3\xa7\xc3\xa3o, e as informa\xc3\xa7\xc3\xb5es sobre as conex\xc3\xb5es entre essas classes s\xc3\xa3o abstra\xc3\xaddas._NEWLINE_Desde quando o LoD exemplifica um tipo espec\xc3\xadfico de acoplamento, e n\xc3\xa3o especifica um m\xc3\xa9todo de endere\xc3\xa7amento deste tipo de acoplamento, \xc3\xa9 mais adequado como uma m\xc3\xa9trica para o "code smell"\xc2\xa0em oposi\xc3\xa7\xc3\xa3o a uma metodologia para a constru\xc3\xa7\xc3\xa3o de sistemas emparelhados.'