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.).

ATENÇÃO! A exibição deste artigo foi interrompida.

  #Este é um post fechado

Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!