Gente, tô desenvolvendo um sisteminha simples de vendas a título de
aprendizado e tô com dificuldades nas classes de venda e produto.
Tipo, como eu controlo, na classe venda, a qtd e o valor unitário de um
determinado produto? Será que é preciso criar uma outra classe (
ItensVenda) pra essa tarefa? Outra dificuldade que tô tendo é com relação
às formas de pagamento (a vista ou parcelado). Tô pensando numa classe
tipo, “Crediario” pra controlar os pagtos. parcelados… é por aí?
Os atributos que abstraí até agora pra classe venda:
public class Venda implements Serializable {
private Integer id;
private Date dtvenda;
private Cliente cliente;
private Set<Produto> produtos;
private Double vlr_total;
...
}
Quaisquer sugestões e exemplos são bem vindos.
Obviamente, qd se está aprendendo a intenção é exercitar um pouco de tudo. Mas, voltando ao caso em questão, minha dificuldade está especificada na mensagem acima. Se vc tiver alguma sugestão, serei grato.
Cara, desculpe, mas eu não acho óvio não. Visto que estamos em um fórum aberto e que muita gente vem aqui pedindo até resposta pra lição de casa fiz essa pergunta pra tentar achar o melhor caminho pra te ajudar.
Vc começou a frase dizendo que está desenvolvendo mas tem dúvidas na modelagem, okay. Vou assumir modelagem.
Já vou avisando que isso pode dar muito pano pra manga pois uma solução que venha a considerar
correta pode não ser vista da mesma forma por outra pessoa okay?
Vamos lá:
vc disse sistema de vendas e já mencionou alguns candidatos para suas classes
principais: produto, venda e forma de pagamento.
Acho que um nome melhor pra venda seria “Pedido”.
Eu vejo Crediário como um tipo de forma de pagamento, não como uma classe.
EDIT: Um Pedido deverá ter um ou mais itens (não deve haver pedido sem item certo?). Vejo aqui mais uma classe: Item de Pedido. Cada uma desses terá um e no mínimo 1 Produto.
Vc pode criar uma classe pra conter os preços dos produtos, então cada Produto poderá
ter zero, um ou mais preços (isso mesmo, se vc pensar em mater o histórico de preços no decorrer
do tempo que acho legal já que vc pode ter algum Pedido antigo e não vai querer que o preço
deste fique incorreto).
Um Pedido pode ter zero, um ou mais Pagamentos.
Cada Pagamento deverá ter uma e no mínimo uma Forma de Pagamento.
Que tal?
Versão 0.1 besta, vamos melhorar isso? Vê aí se tem tudo o quê vc precisa e corta algo que ache desnecessário.
Desculpa aí, cara… é que sou iniciante e não conheço bem os termos corretos (é modelagem mesmo).
Valeu pelas dicas, era isso mesmo que eu tava querendo… sugestões. Com relação as sua proposta de modelagem, ela não tá muito voltada pra banco de dados, não? Eu já li em algum lugar, que iniciar modelagem pensando em BD não é bem visto pela OO.
Se alguém mais quiser opinar, fiquem a vontade.
Obrigado.
Eu tenho uma sugestão, mas foge um pouco do escopo do que você pediu… A princípio eu posso parecer chato, mas quando você for trabalhar em equipe isso será importante. É para seguir as convenções de código do Java. Dê uma olhada nesse link: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
O seu código ficaria desse jeito, por exemplo:
public class Venda implements Serializable {
private Integer id;
private Date dataVenda;
private Cliente cliente;
private Set<Produto> produtos;
private Double valorTotal;
...
}
Os nomes das variáveis seguem o padrão, que é primeira palavra com inicial minúscula e demais com inicial maiúscula e sem _s, e os nomes também estão mais claros… Ao escrever o nome de uma variável tente fazê-lo de modo que se entenda para que ela serve. E, ao fazer isso, pense nas outras pessoas que vão ler o seu código e não apenas em você.
é verdade javabegin, tenho de tomar mais cuidado com isso (tava de guarda baixa - pedido item tá muito no meu sangue e sempre faço em banco).
EDIT: muito bem notado, aliás, parábens (nem todo mundo se toca disso, como pode ver)
Mas ainda está muito próximo do que vc vai precisar.
EDIT: por isso passei o link, os caras já se aprofundaram em um assunto que eu acho semelhante ao seu.
Qto a ser mal visto pela comunidade OO pode sim, mas o que realmente importa é o resultado final. Sempre vai ter gente torcendo o nariz pro trabalho alheio mas não se preocupe com isso, caso contrário nada sai.
Sinceramente, usando hibernate você praticamente não precisa pensar em banco de dados. Eu faço o modelo da minha aplicação, crio os mapeamentos no hibernate e ele faz o trabalho sujo por mim. :lol: Mas a modelagem que você fez não é necessariamente uma modelagem orientada pelo BD. Um diagrama de classes dessa aplicação seria descrito mais ou menos dessa forma mesmo.
Tem razão, é difícil dissociar o BD… tb tenho esse vício (Integer id).
O post que vc indicou tem tudo a ver com o meu caso. Vai ajudar muito.
Brigadão mais uma vez.
David, ele está começando. Não acha que sugerir um hibernate logo de cara não vai fazer com ele deixe de aprender o básico? Aliás, ele ainda precisa saber modelar, questionar os objetos envolvidos (independente de usar ou não hibernate), suas resnponsabilidades e tal, não acha?
Ele viu como modelagem de banco pq eu não extendi o raciocínio. Fiquei muito na básico. Não falei nada de herança, generalização, constraints e daí vai. Realmente isso pode ser lido como banco, IMO.
Não, não tô sugerindo que ele use hibernate. Se pareceu isso me desculpem. Só estou dizendo que é bom você pensar em termos de classes e não de tabelas, que é importante você abstrair o banco de dados. Isso é um trabalho para o futuro, javabegin. Continue esse exemplo que você está no caminho certo.
Tive pensando… se eu usar algum atributo do tipo HashMap (ou algo semelhante), eu consigo elimar as classes de itens disso, itens daquilo…?
Algo do tipo, private HashMap qtdProduto (tomando a classe Venda como exemplo), aonde eu associaria o id do produto à sua quantidade. Que que vcs acham? Tô pensando besteira?
Eu penso da seguinte maneira: existem três entidades envolvidas, Venda, ItemVenda e Produto. Produto é a especificação do material, é um livro, um cd, etc; ItemVenda é aquilo que vai para o cliente e é formado por um Produto mais a sua quantidade, valor ou outros atributos que achar interessante; por fim, Venda é um conjunto de ItemVenda mais um valor total e uma forma de pagamento, por exemplo. É uma sugestão, existem várias possibilidades de se fazer isso. Eu acho que você não deve pensar em economizar classes se elas existem no seu negócio e a existência delas facilita a modelagem e o desenvolvimento.
Edit: Aliás, esse jeito que eu falei foi como o agodinhost falou. Eu concordo com ele. Acho que essa economia que você ia fazer pode tornar as coisas confusas.
Vc poderia fazer isso sim, mas vc teria de, do mesmo modo, criar algum tipo (classse) pra jogar dentro desse hashmap. Vc não vai economizar classe alguma. Dependendo do modelo que vc venha a desenhar isso já vai se fazer necessário - normalmente usamos alguma coleção pra isso (arraylist é mais comum).
Vc vai ter uma coleção dessas na classe Pedido. Lembra que um Pedido tem nenhum, um ou muitos Itens? Pois é, essa frase já te dá a pista pra saber quem vai ‘conter’ a coleção.
Nesse momento vc deve se focar no que vc quer em termos de negócio, o que vc quer manter, abstrair ao máximo suas idéias.
Tô vendo isto na facu (5º perídodo de proc. de dados). Tb andei brincando com o Jude e o Omondo. UML oferece muitas técnicas que são essenciais principalmente na fase inicial da modelagem. Na verdade, acho que a modelagem é parte mais difícil dessa parada toda.
[quote=javabegin]Tô vendo isto na facu[/quote]então aproveita esse assunto e tenta modelar no papel. Vc vai poder exercitar UML e depois, só depois, vc manda ver no código (é mais ou menos como ter uma fase de levantamento e outra de implementação.)
Nas grandes empresas e algumas metodologias vc teria uma fase intermediária, a de projeto (apenas pra ilustrar por alto, antes que alguém me bata).
Na fase de levantamento vc está preocupado com o seu negócio (business, espero que não vire piada). Nesta fase vc não deve se preocupar em como resolver os problemas ok? Normalmente vc desempenha o papel de analista qui.
Depois é a vez do projeto, que é onde vc busca soluções tecnológicas para os seus problemas de negócio. Aqui o papel é de projetista.
Por último vem a codificação.
Sacou?
A TODOS: se alguém tiver alguma correção ou adendo, por favor, sintam-se à vontade (óbvio ululante).