Lei de Demétrio e Agregação

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Estava lendo sobre a lei de demétrio que fala sobre os objetos não podem se comunicar com estranhos.
ex:

Pela essa lei isso é uma má prática. Seria um método frágil.
Porque frágil ?
Seria ideal isso:

Agora esse padrão não tira a reusabilidade, ou seja, não criarei redundancias e a cada método adicionado na filial terei que adicionar um método no funcionario ?
Imagina se houver um nível de agregação extremamente cascateado ?
Gostaria da opinião de vcs.

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

Também li algumas dicussões sobre a teoria do cara.

Concordo com você que para aplicações crud bestas (a maioria), que pegam os dados e mostram para o usuário, realmente me parece exagero aplicar a teoria.

Mas cara, brincando de fazer uns joguinhos aqui ... esse lance de getA().getB().getC().fazCoisa() dói. Falta separação de responsabilidades e delegação uma hora faz a coisa desmoronar.

Lembre-se da discussão sobre getters e setters. Mandar o objeto fazer o que você precisa feito é melhor que pegar os dados para fazer você mesmo.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Isso que eu não entendi, por que faz a coisa desmoronar ?
Separando as responsabilidades vc tira as reduncias.
Isso é vital para ter "uma representacao relacional em OO".

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Ja fica menos pior assim:

Deve ser chato, mas poderia-se usar interfaces (funcionario implements filial). Assim,

Internamente seria

Espero nunca pasar por isso.

This message was edited 1 time. Last update was at 06/05/2005 15:38:22

A ideia da interface é boa, mas esse ao meu ver é o problema.
Deixar somente os atributos (métodos acessores) da filial na filial é o interessante.

Imagina se eu tiver 100 classes que tem como atributos o departamento e precisar obter o nome da filial em diversos lugares.
Imagina em cada métodos adicionado na filial tiver que implementar a interface filial em cada dessas classes.

renato3110 wrote:
Espero nunca pasar por isso

Eu acredito que o pessoal tá fazendo igual a primeira maneira sem problemas.
O que eu estou discutindo é a colocação desse Demeter em falar que é uma maneira frágil.
Gostaria de entender...

A lei de Deméter (que era o nome do sistema desenvolvido quando propuseram esta lei)é uma rule of thumb. Ela não explica o porque (apesar dos papers tentarem), mas ela diz: não faça.

Na verdade, se você tem que navegar muito nos seus objetos, e pode ser por um:

ou um:

tanto faz, você está, provavelmente, com um problema na sua modelagem. Pode até ser que você queira e precise pegar o objeto no grafo, mas provavelment eo que você teria que fazer era delegar isso para uma dessas classes de meio de campo.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Shoes se possível dá um exemplo.
O problema de fazer diferente é devido o mapeamento OOxRelacional.
Esse é grande problema.
Você tira a "normalização" das classes.

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

jprogrammer, no seu exemplo você está simplesmente chamando um monte de getters feios para pegar o valor de uma String.
Mas imagine que os objetos são algo mais complexo que pojos. Não te cheira a peixe o Command/Action/etc precisar passar por todo esse caminho para realizar uma tarefa?

Olha que coisa nojenta.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Ficar bonito não fica, mas e o problema do mapeamento relacional.

Este é um dos casos quando você quer e precisa pegar objetos no grafo, mas você não deve basear sua lógica de negócio nessa interface.

Faça aquele esquema Factory/Implementação/Interface

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Mas isso não tira a "normalização" das classes.
Não ficaria estranho isso:

Imagina as inúmeros métodos que tenho que criar conforme for agregando objetos a funcionario e adicionando métodos as classes agragadas.
Imagine num nível de agregação gigantesco...

JavaTeenager Membro desde: 30/04/2004 09:00:53 Mensagens: 169 Offline

Tenho a impressão de não estar entendendo alguma coisa do seu problema...
Parece que vc tem um problema de atribuição de responsabilidades no seu projeto. Não me parece razoável que a classe Funcionário tenha a responsabilidade de conhecer a média salarial do departamento. Vc poderia me dizer para que é exatamente que vc precisa disso em funcionário? Talvez a gente possa ajudar a projetar uma solução melhor com um exemplo concreto.
Como disse o LIPE, o melhor é deixar para quem já tem a informação necessária fazer o que é preciso.
O objeto tem que ter gets/sets somente para os seus atributos normais, e não para os atributos dos seus atributos...
Será que estou falando besteira??

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Não tenho problema nenhum.
É apenas conceitual.

Pela lei de Deméter fazer muiitas chamadas é errado.
Apenas esto querndo entender o porquê (se tem).

This message was edited 1 time. Last update was at 06/05/2005 17:10:16

Muitos getters é sinal de peixe pobre.

O Eclipse, por exemplo, tem os refactoring necessarios para resolver isso. Como exercício, pegue um método cheio disso e faça o seguinte:

1)mova o método para a classe com maior número de getters, setter e métodos invocados.
2)agrupe as declarações de acordo com os tipos envolvidos.
3)extraia métodos menores de acordo com os clusters encontrados no passo 2
4)repita passos 1 a 3 ate não existirem mais getters/setters sendo chamados
5)faça inline dos métodos que são simples demais
6)mova os atributos que tem getters/setters para tipos mais próximos dos que chamam eles
7)repita 1 a 6 até exaustão.

O bonus round é no dia seguinte, compare o original com o resultado e analise se o código melhou ou não.

Se você se sentir realmente desafiado, tem um passo extra entre troque o passo 7 pelos seguintes:

7)garanta que existem menos métodos retornando valores (!= void) que na iteração anterior
8 )repita 1 a 7 até não existirem mais métodos retornando valores ou desmaiar por exaustão

Se isso não fizer você enxergar OO como o Neo vê a matrix, desista.

javinha, você não falou besteira, mas tá no contexto errado

jprogrammer (esses nicks de vocês estão me deixando louco!): sim. Lei de Deméter é como (na verdade, é muito relacionada com) acoplamento: você não vai (e talvez não deveria) se livrar totalmente.

A questão é: será que a rotina que precisa do nome do depto precisa navegar partindo do funcionario? Se sim, ok, vc vai rpecisar fazer isso, se não, você pdoe criar um meio menos acoplado.

Notícias, artigos e o maior fórum brasileiro sobre Java