Qual possui acoplamento menor?

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

rylphs wrote:
Isso foi só um exemplo mais curto. A questão é o que eu devo fazer quando me deparar com esse tipo de situação. Devo criar o objeto dentro da classe, delegar a criação à quem irá chamar o método, ou talvez isso dependa da situação? Gostaria de saber também sobre o uso de interfaces. Sempre devo criar interfaces? É isso que significa "Programe para uma interface, e não para uma classe"?

Mais uma vez, me desculpem por tantas perguntas, mas ainda tenho muito o que aprender.

Obrigado

O exemplo é curto mas serve pra mostrar uma pratica que é muito comum. E quando se deparar com ela deve refatorar para melhor expressar a intencao do codigo. Em se tratando de objetos, alterar os parametros de uma funcao é considerado programacao de risco, voce nao esta reduzindo acoplamento, e sim o contrario.

Baseado no seu exemplo, sim, delegar a criacao do objeto para quem ira chamar o metodo teria um menor acoplamento.

Thread.start() Membro desde: 09/04/2009 06:52:17 Mensagens: 37 Offline

cmoscoso wrote:Em se tratando de objetos, alterar os parametros de uma funcao é considerado programacao de risco, voce nao esta reduzindo acoplamento, e sim o contrario.

Como assim? Não entendi.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

rylphs wrote:

cmoscoso wrote:Em se tratando de objetos, alterar os parametros de uma funcao é considerado programacao de risco, voce nao esta reduzindo acoplamento, e sim o contrario.

Como assim? Não entendi.

O metodo algumaCoisa() esta alterando o objeto passado como parametro (x.facaAlgo()).

Thread.start() Membro desde: 09/04/2009 06:52:17 Mensagens: 37 Offline

cmoscoso wrote:
O metodo algumaCoisa() esta alterando o objeto passado como parametro (x.facaAlgo()).

Ah, entendi! Obrigado.

fantomas wrote:
Sim...

Programar para interface e não para implementação é um dos princípios da OO.

E para suportar essa idéia segue estes itens:

a) O objeto cliente fica independente da implementação do objeto que lhe serve.
b) O objeto que implementa uma interface pode ser facilmente substituido por outro, mesmo dinamicamente.
c) Tem baixo acoplamento.
d) Aumenta as chances de reuso.
e) Aumenta a possibilidade do uso da composição pelo fato de vc poder utilizar vários objetos diferentes mas do mesmo tipo (interface).

flws

fantomas, isso quer dizer que sempre devo criar interfaces e então implementá-las no lugar de apenas criar classes? Isso é uma regra geral, ou específica desse caso?

rylphs,

Acho que a discussão que acontece nesse tópico é bem legal e dá pra tirar alguma conclusão.

Thread.start() Membro desde: 09/04/2009 06:52:17 Mensagens: 37 Offline

Andre Brito wrote:rylphs,

Acho que a discussão que acontece nesse tópico é bem legal e dá pra tirar alguma conclusão.

Obrigado, vou dar uma olhada lá!

This message was edited 1 time. Last update was at 03/06/2009 10:03:29

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:

Por quê não usar assim:

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...

rylphs wrote:fantomas, isso quer dizer que sempre devo criar interfaces e então implementá-las no lugar de apenas criar classes? Isso é uma regra geral, ou específica desse caso?

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

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Andre Brito wrote: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 wrote:Na minha opinião sem usar interfaces ou classes abstratas seu acoplamento sempre será visto como alto.

Fantomas, pode explicar melhor isso?

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.

Thread.start() Membro desde: 09/04/2009 06:52:17 Mensagens: 37 Offline

ramonchiara wrote:Meus 2 cents:
Faltou falar da Lei de Demeter, que está sendo violada...

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.

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?

fantomas wrote:Neste caso vou lhe indicar este livro:

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

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!

rylphs wrote: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 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).

rylphs wrote:Acho que confundi alguns conceitos. 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?

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.

rylphs wrote: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.

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.

Thread.start() Membro desde: 09/04/2009 06:52:17 Mensagens: 37 Offline

Obrigado André Brito.

rodrigoy wrote:Não tem muita relação com acoplamento. Nas duas alternativas a classe está dependendo da Classe X. Se a classe X é abstrata, aí sim a alternativa 1 é menos acoplada. Se não é, tanto faz...

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

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