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?)
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:
S
samurai
e não se esqueção da camada persistência que recebe e evia valores da canada de negócio pro bando.
S
Ssalgado
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:
E
escordeiro
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
danieldestro
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 );
M
mark_domi
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
pcalcado
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
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).
S
Ssalgado
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’ ?
