Dúvida OO x Modelo Relacional x Diagrama de Classes UML

2 respostas
silver00

Pessoal vai ai uma dúvida,

Quando eu tenho um relacionamento muitos pra muitos na maioria dos casos é criado uma classe associativa, ai no digrama de classes vc representa-o como uma terceira classe para resolver os lados muitos de ambas as relações e nessa classe é colocado os atributos que serão comuns ao relacionamento. Até aqui tudo bem, quando pensamos em banco de dados é facil fazer, é criado uma terceira tabela e tals, tudo muito simples. Porém quando implemetaremos isso em classes, devemos codificar essa terceira classe? Pq sempre quando eu implemento algo do tipo eu faço esse tratamento apenas no banco e não na aplicação. Qual seria a forma correta de fazer?

Ex. Cliente, Pedido, ItemPedido.

2 Respostas

TerraSkilll

silver00

Qual seria a forma correta de fazer?

Você precisa compreender que nem sempre existe um jeito "correto" de se fazer. Tudo depende do que você está fazendo e dos requisitos que deve atender/regras de negócio.

O exemplo que você deu (Cliente, Pedido, ItemPedido), numa visão simplista, não cai no problema que você está questionando, porque:
- a relação entre Cliente e Pedido, geralmente, é 1~N (um cliente pode ter vários pedidos, cada pedido pertence a 1 cliente);
- a relação Pedido e ItemPedido, geralmente, é 1~N (um pedido pode ter vários itens, cada item pertence a 1 pedido);
- a relação Cliente e ItemPedido é intermediada pelo Pedido.

Em um banco, seria algo assim:
- tabela Cliente (Codigo, Nome, ....);
- tabela Pedido (Numero, Codigo_Cliente, Total, ....);
- tabela ItemPedido (Numero_pedido, Codigo_produto, Quantidade, ValorUnitario, ....);

Em classes, poderíamos ter algo do tipo:
class Cliente{
private int codigo;
private String nome;
}

class Pedido{
private int numero;
private int codigoCliente;
private float total;
private List<ItemPedido> itens;

public void adicionarItem(ItemPedido item){
itens.add(item);
}
}

class ItemPedido{
// note que a classe ItemPedido, a princípio, não precisa armazenar o nº do pedido,
// porque ela será adicionada ao List que está dentro do Pedido
private int codigoProduto;
private float quantidade;
private float valorUnitario;
}
Acho que, para o que você está questionando, uma estrutura mais próxima seria Representante <--> Cliente, mas partindo do princípio que um cliente possa ter 0 ou N representantes, e um representante ter 0 ou N clientes (veja que é uma requisito). As tabelas seriam: - Cliente (Codigo, Nome, ....); - Representante ( Codigo, Nome, ....); - Cliente_Representante (Codigo_Cliente, Codigo_Representante, ....); Mas a criação das classes poderia variar. Um exemplo:
class Cliente{
private int codigo;
private String nome;
private List<Representante> representantes; // note que o cliente mantém uma lista dos seus representantes;
}

class Representante{
private int codigo;
private String nome;
private List<Cliente> clientes; // note que o representante mantém uma lista dos seus clientes;
}
Não é um exemplo excelente, mas acho que serve para você entender a ideia.

Abraço.

silver00

TerraSkilll me desculpe mas me expressei mal :roll: ao passar a expecificação do problema, mas o que realmente me atende é o seu primeiro exemplo, agora eu entendi como isso é feito “corretamente” por parte da aplicação em si.

Muito obrigado.

Criado 27 de março de 2012
Ultima resposta 27 de mar. de 2012
Respostas 2
Participantes 2