Artigo Java Magazine 26 - Uma Aplicação Java Completa, Parte 2

Java Livre

Uma aplicação Java Completa

Parte 2: JTable, MVC Aplicado e Tratamento de Eventos

Saiba como customizar componentes JTable, organizar o tratamento de eventos, estruturar uma aplicação visual para facilitar extensões e manutenções.

Nesta edição, damos continuidade à construção da aplicação iniciada na edição anterior, apresentando conceitos fundamentais de desenvolvimento Java e recursos da série 4.x do IDE livre NetBeans. A primeira parte foi focada na programação visual e em como o NetBeans pode ser utilizado para prototipar uma interface com usuário baseada  no Swing, além de mostrar características dos principais gerenciadores de layout.

Nesta segunda parte, passamos ao editor de código. Vamos customizar o visual da tabela que exibe as tarefas, para indicar com cores diferentes tarefas completadas, atrasadas ou em estado de alerta. Também iremos tratar dos eventos gerados pelos componentes da interface, evoluir a arquitetura e saber pelos componentes da interface, evoluir a arquitetura e saber como evitar que o tratamento de eventos transforme seu código orientado e objetos em “código espaguete”.

Arquitetura MVC em aplicações Gráficas

Durante a prototipação da interface gráfica, buscamos ficar o máximo possível dentro do editor visual do NetBeans. O objetivo era apenas criar uma “casca” visual para a aplicação que pudesse ser avaliada e discutida com os usuários. Agora vamos começar a colocar lógica por trás dessa casca, permitindo avaliar e testar a real funcionalidade da aplicação.

É comum, no desenvolvimento de aplicações visuais, acabar gerando código desorganizado, onde uma modificação em qualquer parte gera efeitos colaterais nos locais mais inesperados; ou onde a simples adição de uma informação extra exige uma cascata de mudanças em várias partes da aplicação.

Para evitar isso, vamos adotar uma arquitetura muito popular em aplicações interativas, a arquitetura MVC (Movel-View-Controller, Modelo-Visão-Controlador). A MVC foi usada ou descrita em vários artigos na Java Magazine (em maior parte no contexto de aplicações web). Nela, cada classe tem um papel bem definido: tratar da exibição das informações (Visão); responder a ações do usuário (Controlador); ou cuidar da consistência e persistência dos dados (Modelo). Classes com papéis diferentes são praticamente independentes entre si, e assim é possível modificá-las sem medo de gerar “efeitos colaterais”. O uso da arquitetura MVC também torna fácil identificar onde fazer cada mudança.

Para tornar o uso da arquitetura bem explícito, iremos organizar as classes Java em três pacotes: todo.visao, todo.controle e todo.modelo.

No pacote visao estão classes gráficas (como janelas ou componentes personalizados), ou classes necessárias para o seu funcionamento. Essas classes não tomam decisões a respeito de como uma operação deve ser realizada – este é o papel das classes do pacote controle, as quais efetivamente respondem aos eventos do usuário (como cliques num item de menu) e decidem qual operação realizar. Já as classes do pacote modelo representam os dados da aplicação, e contêm a inteligência necessária para realizar ações sobre esses dados.

  Figura 1. Dependências entre componentes no modelo MVC

A Figura 1 ilustra o relacionamento entre os pacotes, usando um diagrama UML (o desenho de pasta representa um pacote e agrupa várias classes)¹. Observe que o Controlador fica no “meio do caminho” entre a Visão e o Modelo². Essa separação traz um benefício adicional: ela permite que uma mesma Visão seja reutilizada com vários Modelos contendo as mesmas informações – mas obtendo essas informações de fontes diferentes (ex.: um Modelo baseado em banco de dados e outro acessando arquivos XML). Pelo seu lado, o Modelo fica independente da interface com o usuário (que faz parte da Visão): as classes do Modelo podem, por exemplo, ser utilizadas depois, numa aplicação web ou num MIDlet J2ME.

Inteligência em objetos

No início da Orientação a Objetos, era comum defender-se a idéia de que um objeto deveria conter toda a “inteligência”relacionada a ele. Mas com o passar do tempo verificou-se que essa estratégia poderia levar a objetos “gordos”, concentrando mutas funcionalidades,e com manutenção difícil  e baixo desempenho. Hoje, no entanto, se considera uma alternativa válida criar também objetos “burros”, que apenas trafegam informações de um “objeto inteligente” para outro, deixando-os mais independentes entre si.

No nosso caso, os “objetos burros” serão Value Objects (VOs)( que são JavaBeans, com atributos  e seus métodos get/set, e possivelmente alguma funcionalidade localizada). E os objetos inteligentes são os objetos de Visão, Modelo e Controle.

A única classe VO de que necessitamos agrupa todas as informações de uma tarefa, então este será o seu nome. Na nossa aplicação, teremos classes de Visão que sabem representar graficamente uma tarefa, e classes de Modelo que sabem como recuperar e salvar tarefas do bando de dados (ou de um collection etc.).

Para simplificar, a classe Tarefa ( e outros VOs que surgirem) podem ser deixados no mesmo pacote das classes de Modelo. Afinal, são as operações implementadas no Modelo que determinam quais informações deverão estar nos VOs.

Arquitetura da aplicação

Nossas classes de Visão – ListaTarefas (um JFrame) e EditaTarefa (um JDialog) – foram prototipadas no artigo anterior. Agora estamos preocupados em definir a interface externa destas classes, isto é, o que irão expor para o Controlador. Precisamos definir os eventos, que representam ações realizadas pelo usuário, e os métodos para manipular informações encapsuladas em VOs.

Teremos apenas uma classe no Controlador, chamada ConsultaEditaTarefas.

 Em aplicações mais complexas, poderá haver várias classes controladoras. Uma estratégia para começar é criar um controlador para cada conjunto de operações consultar-editar-apagar da aplicação.

Nosso exemplo também terá apenas uma classe no Modelo, chamada  GerenciadorTarefas. Esta classe é um DAO (Data Access Object) e será responsável por ler e atualizar registros no banco de dados.

Aplicações mais complexas terão classes de Modelo que encapsulam processos de negócios em vez de apenas entidades de informação.

E irão para o Controlador apenas estas classes de mais alto nível, reservando os DAOs para uso interno.

Na Figura 2 temos um modelo UML contendo as classes que iremos desenvolver. Note como todas as classes no diagrama têm dependências em relação ao VO Tarefa. (Mas como este não tem inteligência significativa, ele é com freqüência omitido em diagramas de classes, e na avaliação de dependências entre classes da aplicação).

Começando a construção

 Nossa idéia é prosseguir construindo a aplicação “de cima para baixo”. Iniciamos pela interface com o usuário (Visão) e vamos descendo até chegar à logica de banco de dados (Modelo). Em cada etapa será feito o mínimo de trabalho necessário para que seja possível testar uma nova funcionalidade. Assim, nossos objetos de modelo serão por algum tempo versões temporárias, mantendo os dados em memória sem acessar o bando de dados." [...] continue lendo...