Estruturando melhor aplicativos com UI (User Interface)

[Neёlix 0]

Estruturando melhor aplicativos com UI (User Interface)

 

Uma das diversas vantagens de utilizar linguagens de programação orientada a objetos é a facilidade que temos em agrupar funcionalidades semelhantes (ou iguais) em classes distintas, mantendo o seu código mais organizado e fazendo com que cada classe seja responsável por uma parte da aplicação. Isto, além de melhorar a leitura e entendimento do código, ainda facilita sua manutenção (implementar novas funcionalidades, atualizar funcionalidades existentes, entre outras coisas...).

 

Imagine que você iniciou um projeto. Criou sua interface gráfica e os métodos que tratam os eventos ocorridos na mesma em uma classe chamada "MyWindow". OK, agora pense: não seria melhor separar cada responsabilidade em classes diferentes? Uma para criar e exibir sua UI (a própria classe "MyWindow" e outra para tratar os eventos (por exemplo: "WindowControl"). Mas, eu utilizo builder e crio o código "arrastando componentes". Não é mais fácil que gastar tempo quebrando a cabeça separando cada coisa na sua determinada classe? Depende. Builders, além de criar um código fonte automático SUJO ainda chamam diversos métodos implicitamente, tornando a leitura do mesmo complicada e consequentemente mais demorada em casos em que é necessário resolver bugs ou criar novos tratamentos. Exemplo de UI criado no NetBeans usando Builder para tratar o evento de um botão:

 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

Isto é um código que tem como responsabilidade: criar um form com um botão central que, ao ser clicado deverá mostrar uma mensagem "Funcionou".

 

 

Agora imagine um código com diversos botões, labels, checkboxes, etc? Não seria mais fácil dividir nosso código, criar NA UNHA uma classe para instanciar e exibir um form, outra para tratar os eventos ocorridos nela? Uma coisa é certa, passe o tempo que for... você saberá exatamente onde deve ser feita a manutenção do código. Por exemplo: O tratamento de um botão está errado, onde devo ir? Na classe que mostra a janela ou na que trata os eventos? Ah, faltou um botão na minha UI, em qual classe devo ir para criá-lo? Na classe que trata os eventos? Não.

 

 

Pare. Pense. Codifique.

Antes de iniciar a escrever o código, pare e pense: Como dividí-lo? Qual a responsabilidade de cada classe?

Programas mais complexos, em sua maioria utilizam o modelo de desenvolvimento MVC, que separam as responsabilidades do programa em camadas distindas: Modelo, Visão e Controle. Onde o modelo é responsável pela persistência dos dados durante a execução da funcionalidade e pelo tratamento de regras de negócio inerentes ao mesmo. A camada Visão é responsável pela interface entre a funcionalidade e o usuário que interagem com a mesma (sim, a janelinha que vemos). Por fim, a camada Controle é responsável pela ligação entre as outras duas camadas e por regras de negócios não específicas à camadade de Modelo.

 

O Nosso exemplo é simples e pode ser dividido em duas classes apenas. Uma para tratar os eventos e outra para criar a UI.

 

 

Minha UI

 

Vide código:

 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

Só de "bater o olho", percebe-se que a classe apenas irá criar uma janela e exibi-la (usei alguns métodos para gerir o modo como a janela será exibida, isto é opcional).

A única novidade é um método que retorna "btCliqueAqui". Mas afinal, para que? Como nosso botão é private (ou seja, somente a própria classe tem acesso a ele) nós precisaremos de um método para retorná-lo. Assim, podemos usar o método "getText" para verificar o texto do botão e com isto poderemos distingui-lo dos demais (Esta não é a ÚNICA forma de fazer isto, há vários outros métodos). Bom, vamos criar a classe que controla as ações?

 

 

Classe Controladora

 

Vide código:

 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

Bem curta (literalmente) e direta, não?! rsrsrs.

Nossa classe vai herdar métodos de JFrame (isto é opcional, eu o fiz pois precisaremos de alguns métodos para tratar componentes).

Nossa classe também irá implementar os métodos abstratos de ActionListener (que é a classe responsável por tratar eventos do mouse: focus, click, pressed, entered...).

 

Nada de tão "assustador" para quem tem um conhecimento básico e sabe alguns conceitos de orientação a objetos. Apenas vamos destacar alguns pontos importantes:

 

public ControlMainWindow (MainWindow mw)

 

Nosso construtor receberá como argumento a nossa classe que cria/exibe nossa UI. Sim, é possível enviar OBJETOS como argumento para um método/construtor.

Lembra que as classes são distintas? Isto é, uma não tem "conhecimento" da outra, então precisamos fazer com que a classe controladora VEJA a classe que contém nossa UI.

 

mainWindow = mw;

mainWindow.getBtCliqueAqui().addActionListener(this);

 

Neste ponto, nossa classe controladora sabe da existencia da nossa UI. Lembra daquele método criado para "pegar" o botão da nossa UI? Pois bem, aqui ele entra em uso.

"getBtCliqueAqui" retorna nosso botão e usamos o método "addActionListener" para "apontá-lo" para esta classe usando o this (se outra classe fosse responsável pelo tratamento, bastaria coloca-la no lugar do this). Neste ponto nossa classe controladora já tem ciencia que existe um botão na nossa UI, mas ainda assim não será feito nada.

 

Implementamos o método "actionPerformed" que tem como parametro uma ação.

JButton bt = (JButton)e.getSource();

Criamos um botão (por isto fiz a classe herdar atributos de JFrame). O método "getSource" retorna um monte de coisas de um determinado objeto, literalmente UM MONTE DE COISAS! Então, precisamos fazer cast para o retorno ser um JButton, assim o que retornar será um botão. Sabendo que os botão da nossa UI tem um texto especifico ("clique aqui"), podemos usar o método getText (que retorna uma string contendo o texto do botão) para distinguir qual botão foi clicado. Isto é feito no switch:

 

switch (bt.getText())

 

Assim que o botão for pressionado, será disparado um evento. Nossa classe controladora irá tratá-lo, verificando o texto do objeto clicado e iniciando sua devida funcionalidade. No nosso caso, seria apenas isto:

 

 

removi a borda do botão, por isso ficou "sem graça" assim.

 

MAS e o método main() ?

 

O método main será usado somente para instanciar a classe controladora e a UI. Nada de enche-lo com código:

 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

Em suas aplicações usando linguagens O.O. (orientada a objetos) tente separar cada responsabilidade em uma classe única. Um exemplo: classe "x" será responsável SOMENTE por criar uma telinha, já a classe "y" tratará SOMENTE seus eventos e uma classe "z" irá verificar SOMENTE se o que foi digitado (por exemplo) em um label "seu nome aqui" é uma string. :)

 

Isto pode dar trabalho, mas a médio-longo prazo facilitará (e muito) as suas manutenções.

 

Em breve escrevo um sobre MVC e obrigado pela leitura.

 

Neelix.

[ratiquinho 2]

Até gostei do tópico porem é mt complicada essa linguagem eu tou mais acustumado com o Visual Basic mais boa iniciativa vai ajudar aos novatos de Java.

[SeMorriFoiLeg 0]

Estruturando melhor aplicativos com UI (User Interface)

 

Uma das diversas vantagens de utilizar linguagens de programação orientada a objetos é a facilidade que temos em agrupar funcionalidades semelhantes (ou iguais) em classes distintas, mantendo o seu código mais organizado e fazendo com que cada classe seja responsável por uma parte da aplicação. Isto, além de melhorar a leitura e entendimento do código, ainda facilita sua manutenção (implementar novas funcionalidades, atualizar funcionalidades existentes, entre outras coisas...).

 

Imagine que você iniciou um projeto. Criou sua interface gráfica e os métodos que tratam os eventos ocorridos na mesma em uma classe chamada "MyWindow". OK, agora pense: não seria melhor separar cada responsabilidade em classes diferentes? Uma para criar e exibir sua UI (a própria classe "MyWindow" e outra para tratar os eventos (por exemplo: "WindowControl"). Mas, eu utilizo builder e crio o código "arrastando componentes". Não é mais fácil que gastar tempo quebrando a cabeça separando cada coisa na sua determinada classe? Depende. Builders, além de criar um código fonte automático SUJO ainda chamam diversos métodos implicitamente, tornando a leitura do mesmo complicada e consequentemente mais demorada em casos em que é necessário resolver bugs ou criar novos tratamentos. Exemplo de UI criado no NetBeans usando Builder para tratar o evento de um botão:

 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

Isto é um código que tem como responsabilidade: criar um form com um botão central que, ao ser clicado deverá mostrar uma mensagem "Funcionou".

 

 

Agora imagine um código com diversos botões, labels, checkboxes, etc? Não seria mais fácil dividir nosso código, criar NA UNHA uma classe para instanciar e exibir um form, outra para tratar os eventos ocorridos nela? Uma coisa é certa, passe o tempo que for... você saberá exatamente onde deve ser feita a manutenção do código. Por exemplo: O tratamento de um botão está errado, onde devo ir? Na classe que mostra a janela ou na que trata os eventos? Ah, faltou um botão na minha UI, em qual classe devo ir para criá-lo? Na classe que trata os eventos? Não.

 

 

Pare. Pense. Codifique.

Antes de iniciar a escrever o código, pare e pense: Como dividí-lo? Qual a responsabilidade de cada classe?

Programas mais complexos, em sua maioria utilizam o modelo de desenvolvimento MVC, que separam as responsabilidades do programa em camadas distindas: Modelo, Visão e Controle. Onde o modelo é responsável pela persistência dos dados durante a execução da funcionalidade e pelo tratamento de regras de negócio inerentes ao mesmo. A camada Visão é responsável pela interface entre a funcionalidade e o usuário que interagem com a mesma (sim, a janelinha que vemos). Por fim, a camada Controle é responsável pela ligação entre as outras duas camadas e por regras de negócios não específicas à camadade de Modelo.

 

O Nosso exemplo é simples e pode ser dividido em duas classes apenas. Uma para tratar os eventos e outra para criar a UI.

 

 

Minha UI

 

Vide código:

 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

Só de "bater o olho", percebe-se que a classe apenas irá criar uma janela e exibi-la (usei alguns métodos para gerir o modo como a janela será exibida, isto é opcional).

A única novidade é um método que retorna "btCliqueAqui". Mas afinal, para que? Como nosso botão é private (ou seja, somente a própria classe tem acesso a ele) nós precisaremos de um método para retorná-lo. Assim, podemos usar o método "getText" para verificar o texto do botão e com isto poderemos distingui-lo dos demais (Esta não é a ÚNICA forma de fazer isto, há vários outros métodos). Bom, vamos criar a classe que controla as ações?

 

 

Classe Controladora

 

Vide código:

 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

Bem curta (literalmente) e direta, não?! rsrsrs.

Nossa classe vai herdar métodos de JFrame (isto é opcional, eu o fiz pois precisaremos de alguns métodos para tratar componentes).

Nossa classe também irá implementar os métodos abstratos de ActionListener (que é a classe responsável por tratar eventos do mouse: focus, click, pressed, entered...).

 

Nada de tão "assustador" para quem tem um conhecimento básico e sabe alguns conceitos de orientação a objetos. Apenas vamos destacar alguns pontos importantes:

 

 

 

Nosso construtor receberá como argumento a nossa classe que cria/exibe nossa UI. Sim, é possível enviar OBJETOS como argumento para um método/construtor.

Lembra que as classes são distintas? Isto é, uma não tem "conhecimento" da outra, então precisamos fazer com que a classe controladora VEJA a classe que contém nossa UI.

 

 

 

Neste ponto, nossa classe controladora sabe da existencia da nossa UI. Lembra daquele método criado para "pegar" o botão da nossa UI? Pois bem, aqui ele entra em uso.

"getBtCliqueAqui" retorna nosso botão e usamos o método "addActionListener" para "apontá-lo" para esta classe usando o this (se outra classe fosse responsável pelo tratamento, bastaria coloca-la no lugar do this). Neste ponto nossa classe controladora já tem ciencia que existe um botão na nossa UI, mas ainda assim não será feito nada.

 

Implementamos o método "actionPerformed" que tem como parametro uma ação.

 

Criamos um botão (por isto fiz a classe herdar atributos de JFrame). O método "getSource" retorna um monte de coisas de um determinado objeto, literalmente UM MONTE DE COISAS! Então, precisamos fazer cast para o retorno ser um JButton, assim o que retornar será um botão. Sabendo que os botão da nossa UI tem um texto especifico ("clique aqui"), podemos usar o método getText (que retorna uma string contendo o texto do botão) para distinguir qual botão foi clicado. Isto é feito no switch:

 

 

 

Assim que o botão for pressionado, será disparado um evento. Nossa classe controladora irá tratá-lo, verificando o texto do objeto clicado e iniciando sua devida funcionalidade. No nosso caso, seria apenas isto:

 

 

removi a borda do botão, por isso ficou "sem graça" assim.

 

MAS e o método main() ?

 

O método main será usado somente para instanciar a classe controladora e a UI. Nada de enche-lo com código:

 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

Em suas aplicações usando linguagens O.O. (orientada a objetos) tente separar cada responsabilidade em uma classe única. Um exemplo: classe "x" será responsável SOMENTE por criar uma telinha, já a classe "y" tratará SOMENTE seus eventos e uma classe "z" irá verificar SOMENTE se o que foi digitado (por exemplo) em um label "seu nome aqui" é uma string. :)

 

Isto pode dar trabalho, mas a médio-longo prazo facilitará (e muito) as suas manutenções.

 

Em breve escrevo um sobre MVC e obrigado pela leitura.

 

Neelix.

 

Parabéns pelo tópico...

informo que sou meio leigo em java e sem tempo para aprender no momento '-'

Mas vai ser muito útil à essa nova geração ! :D