Estou desenvolvendo um projeto para aprender Java e Firebird. No meu sistema tem as seguintes tabelas: Produtos, Grupos, Fornecedores, Cidades e Estados.
Minhas dúvidas são:
Criei na classe do JFrame do cadatro_Produtos os encapsulamentos (gets e sets) da tabela produtos. Minhas dúvidas são:
1ª) Esta correto criar nesta classe (Cadastro_Produtos que é o JFrame) ou seria mais adequado criar uma classe separada do JFrame para a tabela produtos e
extender a classe cadastro_produtos (JFrame) à produtos?
2ª) Se o correto é criar outra classe, como ficaria a questão da classe do JFrame já estende a JFrame, eu não poderia também estender a produtos pois seria heranã múltipla,
sendo assim colocaria produtos como uma interface?
public class Cadastro_Produtos extends javax.swing.JFrame { }
3ª) Toda a validação dos dados das variaveis de instância de produtos devem ser realizadas no método set? Pois acredito que se não for feito assim não teria função o método set.
[quote=rsa_tche]1ª) Esta correto criar nesta classe (Cadastro_Produtos que é o JFrame) ou seria mais adequado criar uma classe separada do JFrame para a tabela produtos e
extender a classe cadastro_produtos (JFrame) à produtos?[/quote]
Nenhum dos dois. O correto é ter duas classes separadas, uma para o JFrame, outra para o Form de cadastro.
Não ficaria. Como o produto não é um formulário de cadastro de produto, e nem vice-versa, são duas classes separadas. Até porque, no futuro você pode querer outro tipo de view para o seu produto (por exemplo um relatório, web, etc.) e não vai querer reprogramar seu sistema inteiro por causa disso.
Exatamente. E o encapsulamento não está completo enquanto você não fizer isso. Também verifique se há necessidade do método set para todos os casos. Muitas vezes, o set é feito indiretamente, através de outro método que garante o estado interno do objeto. Por exemplo, numa classe Semaforo, trocar as cores só poderia ser feito através do método trocaCor(), que garantiria que as cores seriam trocadas numa ordem válida.
Havia outra classe, chamada ClienteDAO, que conteria a lógica de como persistir seu objeto. A lógica pode ser completa (os SQLs, em preparedStatements) ou delegada a um framework de persistência, como o Hibernate. DAOs diferentes podem ser usados para meios de armazenamento diferentes (você poderia ter o MySqlClientDAO e o XMLClientDAO, ambos implementando a interface ClientDAO, um caso típico do padrão Strategy).
Ops, eu quis dizer uma para o Produto, e outra diferente para o JFrame de cadastro. Desculpe pelo erro, foi a pressa.
No caso de aplicações pequenas, você pode evitar usar um framework na camada de controle, e usar as próprias chamadas de função do java. O model e a view também ficam mais próximos.
Aliás, é o que propõe o próprio swing no “simplified model view controller” que ele implementa. Tem um artigo da sun sobre isso, vou ver se acho.