Olá pessoal.
Tenho duas classes com relacionamento many to one e unidirecional entre elas:
class Empresa {
private List<Endereco> enderecos;
// Mais campos
// Construtor
// Getters e Setters
}
E a outra classe:
class Endereco {
// Conteúdo
}
Minha dúvida é se eu transformar o relacionamento entre essas classes em bidirecional vou estar aumentando o acoplamento? No caso a classe Endereco ficaria dessa forma:
class Endereco {
private Empresa empresa;
// Mais campos
// Construtor
// Getters e Setters
}
Se você acha que isto realmente faz sentido para o seu negócio, pode deixar, caso contrário tire. Quem olha de primeira(no meu caso) não parece necessário, mas dependendo das responsabilidades atribuidas a estes objetos pode ser útil ter um relacionamento bidirecional.
ivandasilva, é por que assim. Cada uma dessas classes representam uma tabela no banco de dados. Estou usando o hibernate, caso eu deixe o relacionamento unidirecional ele faz o insert do endereço e logo após faz o update na chave estrangeira empresa. Eu consegui resolver esse problema deixando o relacionamento bidirecional, nesse caso o hibernate já faz o insert com a chave estrangeira. Mas dessa forma eu tive a impressão do aumento do acoplamento dessas classes. Mais tarde eu posso adicionar uma classe Pessoa que tem uma lista de endereços e vou ter que implementar a classe Endereco e assim por diante. Meu objetivo é nunca mais alterar essa classe!
Sim, ao adicionar uma referência à Empresa na sua classe Endereco você está aumentando o acoplamento entre elas.
Ao fazer isso, você pressupões que um Endereço deve necessariamente estar relacionado a uma Empresa, e o que é pior, a EXATAMENTE uma empresa. É claro que só é possível dizer que um modelo está correto dentro de um contexto, mas o fato é que acoplamento sempre tem um custo de manutenção associado, e você tem que avaliar se realmente é necessário.
Talvez você esteja antecipando uma responsabilidade que deva pertencer a algum DAO. Por exemplo, você deve ter pensado que seria interessante que você obtesse uma empresa através de seu endereço. Não seria o caso de deixar o Endereço desacoplado e colocar um método findByEndereco no seu EmpresaDAO ?
Bom, a pergunta foi na verdade a respeito de “Acoplamento” na realidade acoplamento tem a ver com a implementação que você vai fazer no uso do ojbeto dentro da sua classe, se você usar a interface de endereço em empresa, e a interface de empresa em endereço, não vai estar acoplando as classes,
desta forma sempre use as interfaces dos objetos, não acessando diretamente atributos… se as classes não conhecerem mais do que devem sobre as outras não estará aumentanto o “Acoplamento” entre elas…
Pessoal obrigado pelas dicas mas como eu disse é por causa do hibernate que eu fiz o relacionamento bidirecional, caso eu deixe o relacionamento unidirecional ele faz o insert do endereço e logo após faz o update na chave estrangeira empresa. Eu consegui resolver esse problema deixando o relacionamento bidirecional, nesse caso o hibernate já faz o insert com a chave estrangeira. Mas dessa forma eu tive a impressão do aumento do acoplamento dessas classes. Mais tarde eu posso adicionar uma classe Pessoa que tem uma lista de endereços e vou ter que implementar a classe Endereco e assim por diante. Meu objetivo é nunca mais alterar essa classe!
ribclauport, obrigado vou implementar aqui para ver como fica.
[quote]Bom, a pergunta foi na verdade a respeito de “Acoplamento” na realidade acoplamento tem a ver com a implementação que você vai fazer no uso do ojbeto dentro da sua classe, se você usar a interface de endereço em empresa, e a interface de empresa em endereço, não vai estar acoplando as classes,
desta forma sempre use as interfaces dos objetos, não acessando diretamente atributos… se as classes não conhecerem mais do que devem sobre as outras não estará aumentanto o “Acoplamento” entre elas…[/quote]
Ao meu ver esse excesso de desacoplamento gera uma defasagem na coesão. O código vai ficar mais difícil de ler e você terá que ter por exemplo uma interface para uma classe. Isto não é negócio para OO.
Você já não tem a classe Endereço, você apenas mapearia ela em Pessoa
Como você esta mechendo com ORM acho que isto não vai te gerar um custo de manutenção conforme o rmendes08 disse, isto porque, você provavelmente não terá lógica dentro dos seus métodos, eles serão apenas utilizados para acessar atributos privados, então eu pressuponho que não há problemas em ter esse relacionamento bidirecional.
[quote=andreylh]Pessoal obrigado pelas dicas mas como eu disse é por causa do hibernate que eu fiz o relacionamento bidirecional, caso eu deixe o relacionamento unidirecional ele faz o insert do endereço e logo após faz o update na chave estrangeira empresa. Eu consegui resolver esse problema deixando o relacionamento bidirecional, nesse caso o hibernate já faz o insert com a chave estrangeira. Mas dessa forma eu tive a impressão do aumento do acoplamento dessas classes. Mais tarde eu posso adicionar uma classe Pessoa que tem uma lista de endereços e vou ter que implementar a classe Endereco e assim por diante. Meu objetivo é nunca mais alterar essa classe!
ribclauport, obrigado vou implementar aqui para ver como fica.[/quote]
Eu ainda não entendi muito bem o problema … a tabela de endereço que mantém a FK para a empresa ?
[quote] Bom, a pergunta foi na verdade a respeito de “Acoplamento” na realidade acoplamento tem a ver com a implementação que você vai fazer no uso do ojbeto dentro da sua classe, se você usar a interface de endereço em empresa, e a interface de empresa em endereço, não vai estar acoplando as classes,
desta forma sempre use as interfaces dos objetos, não acessando diretamente atributos… se as classes não conhecerem mais do que devem sobre as outras não estará aumentanto o “Acoplamento” entre elas…
Ao meu ver esse excesso de desacoplamento gera uma defasagem na coesão. O código vai ficar mais difícil de ler e você terá que ter por exemplo uma interface para uma classe. Isto não é negócio para OO.
[/quote]
Bom independente de opniões, o que eu disse a respeito de acoplamento no post é o que diz Barte Bates e Kathy Sierra em seu livro. E a respeito de interfaces
IOC trabalha com interfaces para diminuir o acoplamento, sendo desta forma acredito que isso seja negócio para OO.
Com relação ao seu problema de atualização que o hibernate executa de uma pesquisada no atributo “inverse” e também no atributo “cascade” esses dois atrbutos podem te ajudar a não precisar ficar “alterando as coisas” de forma a evitar esse problema, quando voce define o atributo inverse, voce diz quem é o responsavel pelo relacionamento e sendo assim não teria o problema que relatou em atualizações indesejadas do framework.
ribclauport, eu setei inverse como true e cascade.all, mas não resolveu
Andreylh, é o seguinte antes de nos aprofundarmos no problema é bom abordarmos aqui uma coisa por que senão alguém vai ler o post e pensar que estamos ficando loucos, no livro “hibernate in action” criticado por muitos e adorado por poucos, o autor fala a respeito de Relacionamento Pai/Filho, o mesmo explica a respeito de “ciclo de vida”, ou seja se por exemplo um item de um leilão se for deletado, os lances também serão? A resposta é sim, veja que a idéia de acoplamento se toma outro rumo… e como aqui é “Java Básico”, acredito que não seja o lugar certo para discutir um assunto de cunho mais profundo, Em relação a seu problema, por favor post as duas entidades com seus mapeamentos “anotation” ou “xml” e diga o que você quer, por exemplo, voce quer que quando persisitir um endereço não seja persistido uma empresa? você quer como a persistência em “detales”, post ae que a gente resolve.