Como a Lei de Demeter se aplica a sistemas orientados a objetos em relação a acoplamento e coesão? [fechadas]

Como a Lei de Demeter se aplica a sistemas orientados a objetos com acoplamento e coesão?

Eu estava lendo um livro "Desenvolvimento de software e prática profissional" e me deparei com o capítulo sobre LoD e fiquei curioso sobre como esse princípio é aplicado em sistemas orientados a objetos.

De acordo com Emerson Macedo, a Lei de Demeter afirma o seguinte:

• Cada unidade deve ter apenas conhecimento limitado sobre outras unidades: somente unidades "estreitamente" relacionadas à unidade atual.
• Cada unidade deve conversar apenas com seus amigos; não fale com estranhos.
• Fale apenas com seus amigos imediatos.

Isso corresponde diretamente ao princípio do baixo acoplamento, como as unidades (ou objetos) devem, assim como acima:

• Não estar firmemente acoplados um ao outro. Somente os mais próximos são.
• Cada um deve falar apenas com seus colaboradores e não com os colaboradores do colaborador
• Fale apenas com o objeto de colaboração imediata

Uma das formas mais baixas de acoplamento é a passagem de mensagens, ou seja, os dados são compartilhados entre objetos por meio de chamadas de método com parâmetros.

Além disso, pelo que posso ver, a Lei de Deméter não corresponde diretamente ao princípio da alta coesão, uma vez que apenas declara que os próprios objetos devem saber quais dados eles possuem. Um objeto com baixa coesão possui membros de dados que não está usando com freqüência em seus próprios métodos. É mais sobre o conteúdo de um objeto, e não sobre seus relacionamentos e objetos de colaboração.

Acoplamento simplificado

Quando um objeto chama um método, propriedade, etc. de outro objeto, dizemos que os objetos estão acoplados. Chamamos isso de acoplamento porque agora o receptor não pode mudar nada sobre seu próprio método / objeto. sem interromper o chamador .

Assim, quanto mais os métodos de acoplamento, adereços. - mais difícil é alterar o código chamado sem quebrar todo o código que o usa.

contemplando acoplamento

• Referenciando até um único objeto, o método acopla dois objetos.
• Obviamente, o acoplamento é necessário para a criação de software.
• Dada a natureza do acoplamento, nós queremos limitá-lo e isolá-lo. Esse objetivo simplesmente acompanha o desenvolvedor de software geral. princípios.
• Quanto menos objetos tivermos que conversar, menor será o acoplamento.
• Se eu precisar, digamos, 20 chamadas de métodos diferentes, o acoplamento será menor se todas as 20 chamadas forem para uma classe / objeto, vice-versa os mesmos métodos espalhados por várias classes / objetos.

A maioria dos conhecimentos causa acoplamentos malucos

Aqui temos um Employeeque tem um Personque tem um 'Endereço'

public class Employee {
    public Person me = new Person();
}
public class Person {
    public Address home = new Address();
}
public class Address {
    public string street;
} 

Para chegar a rua I devem ligar para: myEmployee.me.home.street. Isso é 180 graus oposto ao princípio do mínimo conhecimento. Eu tenho que saber sobre os internos, a estrutura composta, do Employee, Persone Addressclasses.

Esse design de classe defeituoso me obriga a conhecer todas essas classes e, assim, myEmployee.me.home.streetacopla-me (o objeto chamador) a nada menos que 3 classes - para obter apenas uma propriedade!

Menos conhecimento salva o dia

Se eu falo apenas com a Employeeclasse, estou aplicando o princípio do menor conhecimento em si e, ao fazê-lo, limitamos automaticamente o acoplamento apenas a essa classe e, ao mesmo tempo, isolamos o acoplamento a essa classe.

Adicionando todas as propriedades necessárias na Employeeclasse, corrigimos o acoplamento.

portanto

public class Employee {
    public Person me = new Person();
    public string street { return me.home.street; }
}

Permite-me ligar para: myEmployee.street-

1. Eu "sei" apenas Employee
2. Estou acoplado a apenas Employee- não importa quão complexa seja sua estrutura.

Menos conhecimento até o fim

Nós dissociado myEmployee de Persone Address, e, idealmente, deveríamos continuar a aplicar menos conhecimento adicionando passagem propriedades tais que Employeesó fala Persone Personsó falaAddress

O estudo ( V. Basili, L. Briand e WL Melo. Uma validação de métricas de design orientadas a objetos como indicadores de qualidade ) mostrou que as classes com conjuntos de respostas maiores tendem a criar mais erros do que as classes com conjunto de respostas menor, porque mais conjunto de respostas significa a chance de maior acoplamento.

O valor da Lei de Deméter é que ela reduz a resposta definida por definição. O método de um objeto pode chamar apenas um método em si, qualquer parâmetro que foi passado para o método, método de qualquer objeto que ele criou e método de qualquer objeto mantido diretamente. Como o conjunto de respostas é menor, há menos chances de um acoplamento alto. Como o módulo / método está usando apenas referências imediatas disponíveis, há maior coesão.

É bem simples; diga A depende de B e B depende de C. Sem a Lei de Deméter, você pode usar B e C em A, mas aderindo a essa lei, A depende apenas de B, não pode depender de C.

Isso permite baixo acoplamento, pois reduz bastante o número de dependências de um módulo; a coesão, embora diferente em conceito e acoplamento, é alcançada da mesma maneira. Por ter menos dependências em um módulo, elas se tornam mais específicas para esse módulo e aumentam a coesão. Também o número total de módulos aumentará e eles se tornarão mais especializados para fazer coisas especializadas para o módulo dependente (ao contrário dos objetos divinos), que se traduz diretamente em um sistema mais coerente.