Bom dia pessoal.
Sempre li muito sobre java e fiz pequenos programinhas. Mas queria me aprofundar mais, e por isso resolvi desenvolver um sisteminha para tentar fixar ainda mais a linguagem e consolidar as boas práticas em OO.
Minha dúvida: Fiz um form básico de consultas, que consiste em um JInternalFrame (a classe é filha de JInternalFrame)com botões que todas as telas de consulta terão. Essa classe será a classe pai de todas as telas de consulta.
Pois bem, qual é a melhor forma de tratar os eventos de forma que os forms de consulta filhos possuam as ações padrões do form que estou construindo ? (implementar ActionListener ?).
Pq a minha maior dúvida é como num clique do botão abrir por exemplo, eu chamaria o método da classe Pai e depois colocaria outras modificações inerentes às novas telas(usar super funciona dentro de métodos, ou apenas dentro de construtores?)
Obrigado pessoal, e desculpem o texto grande.
:thumbup:
Ssalgado, não sei se esta é a melhor forma de trabalhar, mas eu sempre faço da seguinte forma
Crio uma classe Form e outra com as Regras de negócios (não coloco nenhuma interação com o Form nesta classe apenas recebe e devolve valores). na classe Form eu coloco vários metodos publicos referentes às alterações que eu quero fazer e no Listener eu apenas acho estas funções.
Ok . Espero ter ajudado :thumbup:
e não se esqueção da camada persistência que recebe e evia valores da canada de negócio pro bando.
Obrigado pela resposta mark_domi.
Vou tentar fazer dessa minha classe apenas um molde para as outras, sem adicionar códigos para os eventos.
mas ai vem mais uma dúvida minha:
para separar as regras de negócio da camada view, se por exemplo eu tenho um JTable a ser preenchida, a forma certa seria passar uma referêcia da minha JTable para a camada de regras de negócio e lá preencher a tabela, ou seja, nem mesmo o preenchimento desta tabela deveria estar na camada view ?
Valeu pessoal :thumbup:
Acho que seria melhor você ter uma classe da view que chamaria a classe de “regra de negócio” e obteria os dados, para então preencher, na view, a tabela; negócio não sabe que JTable existe 
Um sistema que estou refatorando eu fiz assim: criei interfaces para as view, para ter total independência da implementação das telas e desacoplar ao máximo as partes.
A implementação da minha tela tem conhecimento da classe de controle da tela, assim ela pode chamar seus métodos que delegam pro negócio.
E o meu código fica mais ou menos assim:
//retorna o objeto de implementação desejado
CadastroGUI gui = GUIFactory.getCadastroGUI();
gui.setController( this );
gui.start();
E na minha GUI:
//botão foi clicado
controller.cadastrar( pessoa );
Ssalgado, se vc trabalhar com classes do tipo DTO (classes que possuem apenas propriedades e metodos Get´s e Set´s, também conhecida como VO´s) vc pode carregar o DTO e descarrefar, sem ter que passar informação nenhuma da tela, apenas Dados(String, int , date, …)
desta forma dá um pouquinho de trabalho para fazer (se bem que o Eclipse gera os Get´s e os Set´s sozinho), mas na hora de dar manutenção , vc vai ver como fica mais facil e seu código fica mais limpo, vc acaba ganhando tempo, e seu código fica organisado
[quote=mark_domi]mas na hora de dar manutenção , vc vai ver como fica mais facil e seu código fica mais limpo, vc acaba ganhando tempo, e seu código fica organisado
[/quote]
Bem mais estruturado, com bem menos objetos…lindo como um programa em C sem ponteiros :mrgreen:
Correndo o risco de ficar mais repetitivo ainda: só use DTOs se você precisar mandar objetos de uma JVM para outra (ok, estou sendo extremista, joguem tomates).
Valeu passoal, vcs estão ajudando bastante.
Mas fico um pouco confuso, pq não consigo ver como fazer essa divisão, por exempo:
Digamos que eu tenha uma tela principal, que tem botões que chamariam outras telas. Quem tem que saber que janela abrir no clique de um botão , a tela principal ou uma classe com as regras ? O que a camada de apresentação pode ‘saber’ ?