Qual possui acoplamento menor?

Assuntos Gerais Agile
#21

Meus 2 cents:

Faltou falar da Lei de Demeter, que está sendo violada…
No caso que você falou abaixo, você está tentando obter os DAOs de outras classes:

public Class ClasseY{   
    Dao1 d1;   
    Dao2 d2;   
  
   ClasseY(ClasseX x){   
      d1 = x.getDao1();   
      d2 = x.getDao2();   
   }   
  
   public void algumMetodo(){   
     int consulta1 = d1.getAlgumCampo();   
     int consulta2 = d2.getAlgumCampo();   
     ...   
   }   
}

Por quê não usar assim:

public Class ClasseY{   
    Dao1 d1;   
    Dao2 d2;   
  
   ClasseY(Dao1 d1, Dao2 d2){   
      this.d1 = d1;   
      this.d2 = d2;   
   }   
  
   public void algumMetodo(){   
     int consulta1 = d1.getAlgumCampo();   
     int consulta2 = d2.getAlgumCampo();   
     ...   
   }   
}

Pronto, você não está mais dependendo da Classe X e sim apenas dos DAOs, que você queria desde o início…
Alguém comentou de IoC / Injeção de Dependência, que é a solução nesse caso…

#22

Não é regra geral, como disse antes é apenas um dos princípios da OO.

Neste caso vou lhe indicar este livro:

Use A Cabeça! Padroes De Projetos (em Portugues) (2007)
FREEMAN, ERIC / FREEMAN, ELISABETH
ALTA BOOKS
INFORMATICA

http://www.livrariacultura.com.br/scripts/cultura/busca/busca.asp?palavra=padr%F5es+de+projetos&tipo_pesq=titulo&sid=189859771139516865466146&k5=128D6ADD&uid=&limpa=0&parceiro=OTOXAX&x=0&y=0

Existem outros do genero, vale a pena explorar o assunto.

flws

#23

[quote=Andre Brito]Bruno Laturner,
Achei bem colocado o que você disse. Só que o acoplamento, nesse caso, vai existir sempre “do nível de classe”. Então acho que teria mais alguma classe envolvida aí (algo como Façade (não tenho certeza)).

Fantomas, pode explicar melhor isso?[/quote]

Tem razão, nem tinha pensado nas interfaces. Pensei no acoplamento já pensando em diminuir as dependências de sub-sistemas/grupos de classes de outras classes.

Tudo para não virar aquele emanharado de imports no projeto.

#24

[quote=ramonchiara]Meus 2 cents:
Faltou falar da Lei de Demeter, que está sendo violada…
[/quote]

Caramba! Quanto mais eu aprendo, mais eu descubro que tem mais coisa pra aprender. O erro do meu código seria o fato de ele estar pedindo a X que lhe entregue os DAO’s? E se se tratasse de uma fábrica?

Acho que confundi alguns conceitos. :oops: Não sei se são realmente DAO’s. São classes mapeadas para o hibernate, acho que se chamam POJO’s. É a mesma coisa?

[quote=fantomas]Neste caso vou lhe indicar este livro:

Use A Cabeça! Padroes De Projetos (em Portugues) (2007)
FREEMAN, ERIC / FREEMAN, ELISABETH
ALTA BOOKS
INFORMATICA [/quote]

Eu estou lendo o livro padrões de projeto do GOF, mas estou apanhando um pouco pra entender alguns conceitos, principalmente por se tratar de um livro focado em Smalltalk/C++.

Eu estou lendo também “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process”, mas dei uma parada pra investigar melhor os padrões GOF.

Vejo que tem muito conceito, muita coisa relacionada a OO. Eu tenho pesquisado bastante sobre padrôes. Tem mais algum tipo de leitura que vocês me recomendam? Algo que fale sobre coisas como essa lei do Demeter, talvez.

Muito obrigado galera, vocês estão realmente me ajudando muito! :smiley:

#25

Acho que essa “fábrica” seria uma das interfaces. Não sei se o que vou falar é certo, mas seria alguma coisa do tipo ter uma interface DAO geral, com as outras DAOs como subclasse, que vão dizer como pegar os dados (tipo DAODoCliente, que vai pegar os dados do cliente e mandar pra “camada de negócio”).

Além disso, você poderia usar fábrica (ou Factory), pra fazer uma classe geral (quer seria uma interface também) e fazer outras classes Factory criarem os DAOs. Essas fábricas que iriam decidir qual tipo de acesso seria feito (usando XML, banco de objetos, banco relacional e por aí vai).

Acho que não cara. POJO é tipo uma entidade. Uma classe Cliente com nome, telefone, endereço, por exemplo. DAOs são classes onde métodos como acessarPorNome, acessarPorTelefone, acessarPorEndereço vão.

[quote=rylphs]Eu estou lendo o livro padrões de projeto do GOF, mas estou apanhando um pouco pra entender alguns conceitos, principalmente por se tratar de um livro focado em Smalltalk/C++.

Eu estou lendo também “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process”, mas dei uma parada pra investigar melhor os padrões GOF.[/quote]
O Head First é mais fácil de ler, mas é complicado viver sem o do GOF. Acho que este último não serve como um textbook, mas sim como um livro de consulta. Já o Head First é mais tranquilo de ler.

Não leve tudo o que falei como “resposta de Deus”. Eu não lidei com isso ainda, então não tenho uma base muito forte pra te dizer.
Abraço.

#26

Obrigado André Brito.

#27

Na verdade faz diferença pois na primeira alternativa da pra fazer um mock pra testar já na segunda não.

#28

Tem certeza disso? rsrs

Bom, para as classes “chamadoras”, não importa o que o método faz internamente. Porém, a pergunta sobre acoplamento é da classe que implementa o método.
Nesse caso, concordo com a resposta do rodrigoy.

A estrutura ao redor da implementação desse objeto teria que ser muito bem elaborada para que diminuisse o acoplamento.
Repare que eu disse “diminuir”. Em ambas as situações, a dependencia ainda existirá.

Até.

#29