Criando aplicações Web com EJB e padrões de projeto

Assim que um programador ganha experiência na linguagem Java, começa a se deparar com situações comuns em vários tipos de projetos que demandam algum tipo de solução padronizada. Na cabeça do desenvolvedor, deve surgir um pensamento semelhante a este: “essas situações ou problemas, que provavelmente já foram enfrentadas por outros desenvolvedores anteriormente, devem possuir uma forma ideal de serem solucionadas ou implementadas”. E muitas destas formas realmente existem: são os chamados “padrões de projeto” (design patterns).

O importantíssimo livro Design Patterns: Elements of Reusable Object-Oriented Software (com o título nacional “Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos”), de autoria da chamada “Gang of Four” (“Turma dos Quatro”: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides), foi o grande responsável por popularizar o termo “padrão de projeto” em software, como uma espécie de “receita básica” para a solução de problemas comuns em projetos orientados a objetos.

Publicado em 1994, o livro traz uma série de situações e problemas comuns em softwares orientados a objetos e as respectivas “soluções ideais”, as quais foram denominadas de “padrões de projeto”. Apesar dos exemplos do livro estarem originalmente em C++ e Smalltalk, podem (e devem) ser aplicados a qualquer linguagem de programação orientada a objetos. Obviamente, estes também possuem implementação em Java.

No livro, os padrões de projeto são divididos em três categorias:

• Padrões Criacionais (creational patterns): usados para criação de objetos seguindo alguma regra, sem que estes precisem ser instanciados diretamente. É dentro desta categoria que ficam, por exemplo, dois padrões que são “velhos conhecidos” dos desenvolvedores: o Singleton, que estabelece uma única instância compartilhada para um objeto, e o Factory Method, onde um método é usado para retornar uma nova instância de uma classe;
• Padrões Estruturais (structural patterns): servem para definir a estrutura e composição dos objetos e classes. O padrão de projeto Façade, amplamente usado em aplicações Web com Enterprise JavaBeans, faz parte desta categoria;
• Padrões Comportamentais (behavioral patterns): são aqueles que estabelecem padrões de comportamento e funcionamento dos objetos, mais especificamente a maneira como estes se comunicam. Dentro desta categoria está o padrão Observer, que estabelece um objeto “observador” que deverá ser notificado no caso de uma mudança de estado em algum outro objeto.

É muito provável que você, mesmo sem saber sobre o conceito de padrões de projeto, já tenha se deparado com alguns deles em programas Java. O padrão criacional Factory Method, por exemplo, é usado em diversas classes da linguagem para retornar uma nova instância de um objeto, assim como o Singleton, que traz uma instância única compartilhada.

Outro padrão de projeto muito utilizado é o conhecido MVC (Modelo-Visão-Controle). Este padrão foi estabelecido em 1979 por Trygve Reenskaug, para uso com a linguagem Smalltalk.

O MVC define três divisões (ou camadas) básicas para um aplicativo:

• Modelo: consiste nos dados e na lógica existente na operação destes;
• Visão: é a interface do aplicativo, aquilo que efetivamente será apresentado ao usuário;
• Controle: tem o papel de fazer a “ponte de comunicação” entre o modelo e a visão.

A ideia central por trás do MVC é desacoplar o máximo possível o Modelo da Visão, de forma que sejam independentes. Dessa maneira, os elementos pertencentes a estas duas categorias terão sua possibilidade de reutilização maximizada.

Veja no diagrama da Figura 1 um exemplo de como deve ser a comunicação entre os elementos de um sistema implementado com MVC.

O MVC é considerado como um padrão do tipo estrutural e, apesar de ser citado no livro Design Patterns, não é incluído como um dos “padrões de projeto” efetivos desta obra. Ao invés disso, Gamma, Helm, Johnson e Vlissides “decompõem” o MVC em três outros padrões definidos no livro: o Observer, o Composite e o Strategy.

As vantagens de reutilização proporcionadas pela divisão de uma aplicação nestes três “campos” do MVC são bastante óbvias. A interface de uma aplicação, a Visão do MVC, é geralmente “amarrada” a uma plataforma específica, e sua portabilidade é bastante limitada. Já as classes que definem o Modelo, desacopladas de uma interface específica, podem ser intercambiadas e reutilizadas em diversos projetos."