que a torna uma plataforma útil para desenvolvimento de aplicações Web e Web
Services.
Para camada de acesso aos dados, pode-se UTILIZAR as seguintes tecnologias:
• Hibernate (Gonçalves,2007) - É um projeto que procura soluções completas para o problema de gerenciamento de dados persistentes em JAVA. O hibernate é um
framework que se relaciona com o banco de dados, onde esse relacionamento é
conhecido como mapeamento objeto/relacional para JAVA, deixando o desenvol- vedor livre para se concentrar em problemas da lógica de negócios. O hibernate se integra ao sistema se comunicando com o banco de dados como se fosse direta- mente feito por sua aplicação. Uma mudança de banco de dados, nesse caso, não se torna traumática, alterando apenas um ou outro detalhe nas configurações; e
• Java DataBase Connection (JDBC) (Reese,2001) - Percebendo o aumento no nú- mero de API proprietárias para acesso a banco de dados, a SUN desenvolveu uma API única para acesso a banco de dados, aJDBC. JDBCé uma API que permite acessar banco de dados e construir instruções Structured Query Language (SQL)
e incorporá-las dentro de chamadas de API Java, usando basicamente a lingua- gemSQL. JDBCpermite-se traduzir harmoniosamente entre o mundo de banco de dados e o mundo das aplicações Java. Seus resultados do banco de dados são retornados como objetos Java e os problemas de acesso são considerados exce- ções.
2.6
Padrões de projeto
A ideia de padrões foi inicialmente idealizada por Christopher Alexander ao se fazer a seguinte pergunta: O que está presente em um projeto de boa qualidade que não
está presente em um projeto de baixa qualidade? Observando as estruturas, Alexander
percebeu que ele poderia discernir similaridades entre fatores que resultaram em projetos de alta qualidade, e a esses fatores ele deu o nome de padrões. Cada padrão descreve um problema que ocorre repetidamente em nosso ambiente e, portanto, descreve o cerne da solução desse problema, de tal forma que se pode utilizar essa solução várias vezes repetidas, sem nunca fazê-la duas vezes do mesmo modo (SHALLOWAY and TROTT,
2002;GAMMA et al.,1995).
Foi com base nas pesquisas de Alexander que Erich Gamma, Richard Helm, Ralph
2.6. PADRÕES DE PROJETO
estruturais de software, formalizando vinte e três padrões de projeto classificados em três propósitos, criação, estrutural e comportamental. Os padrões de criação se preocupam com o processo de criação dos objetos. Os padrões estruturais lidam com a composição de classes ou de objetos. Os padrões comportamentais caracterizam as maneiras pelas quais classes ou objetos integram e distribuem responsabilidades. Esses padrões ficaram conhecidos como padrões GOF (Gang Of Four) ou gangue dos quatro (Lasater, 2006;
GAMMA et al.,1995).
Mas o que são exatamente padrões de projeto? Segundo Braude (2004), padrões são combinações de classes e algoritmos associados que cumprem com propósitos co- muns de projeto. Um padrão de projeto, segundoGAMMA et al.(1995), nomeia, abs- trai e identifica os aspectos-chave de uma estrutura de projeto comum para torná-la útil para criação de um projeto de software orientado a objetos reutilizável. Ainda segundo
GAMMA et al. (1995), projetar software orientado a objetos é difícil, mas projetar
software reutilizável orientado a objeto é ainda mais complicado. Por esse motivo que
projetistas experientes preferem reutilizar estruturas ao invés de desenvolver uma do zero.
2.6.1
O padrão estrutural Decorator
Sua intenção é agregar responsabilidades adicionais a um objeto de forma dinâmica. Os decorators fornecem uma alternativa flexível ao uso de subclasses para extensão de funcionalidades. Uma forma de adicionar responsabilidade é através do uso de herança.
Decorator utiliza herança para adicionar funcionalidades dinamicamente a um objeto.
Por exemplo, um toolkit para construção de interfaces gráficas deve permitir a adição de propriedades, como bordas, ou comportamentos, como rolamento de tela (GAMMA et al.,1995).
O padrão decorator trabalha permitindo criar uma cadeia de objetos que inicia com os Decorators, os quais são responsáveis pelas novas funções. O diagrama de classe do padrão decorator, mostrado na Figura2.9, contém uma cadeia de objetos, Scrolldecora-
tor e Borderdecorator, cada cadeia inicia com uma classe componente (seja componente
concreto ou decorator). Cada decorator é seguido de outro decorator ou o componente concreto original. Uma classe componente concreta sempre encerra a cadeia (SHAL- LOWAY and TROTT,2002).
2.6. PADRÕES DE PROJETO
Figura 2.9 Diagrama de Classes do padrão Decorator (SHALLOWAY and TROTT,2002)
SegundoGAMMA et al.(1995), deve-se usar decorator para:
• Acrescentar responsabilidade a objetos individuais de forma dinâmica e transpa- rente, ou seja, sem afetar outros objetos;
• Responsabilidades que podem ser removidas;
• Quando a extensão através do uso de subclasse não é prática. Às vezes, um grande número de extensões independentes é possível e isso poderia produzir uma explo- são de subclasses para dar suporte a cada combinação. Ou a definição de uma classe pode estar oculta ou não estar disponível para utilização da classe.
2.6.2
O padrão comportamental Strategy
Um padrão de estratégia é um conjunto de algoritmos encapsulados dentro de classe intercambiáveis que possibilitam que o algoritmo possa variar dependendo da classe utilizada. As estratégias são utilizadas quando se deseja decidir em tempo de execução a utilização de cada algoritmo. Essa variação entre os algoritmos fica sob responsabilidade da classe contexto (Lasater,2006).
O padrão Strategy tem três componentes principais: the Strategy, the Concrete Stra-
tegy e Context. O componente Strategy é uma interface comum que une todos os algo-
ritmos implementados no padrão. Normalmente essa classe é abstrata. O componente
Concrete Strategy é a classe de implementação, é nela que se encontra toda a lógica dos
2.6. PADRÕES DE PROJETO
de quantas estratégias concretas se deseja usar. O componente Context é o objeto que as- socia uma estratégia concreta a um fluxo de código específico (Lasater,2006). A Figura
2.10mostra o diagrama de classes do padrão Strategy.
Figura 2.10 Diagrama de Classes do padrão Strategy (Lasater,2006)
Vantagens de se utilizar o padrão Strategy (SHALLOWAY and TROTT,2002).
• Define uma família de algoritmos;
• Os comandos switch e/ou condicionais podem ser eliminados; e
• Deve-se invocar todos os algoritmos da mesma maneira. A interação entre as classes concretas e de contexto pode requerer a adição de novos métodos, o que pode ser facilmente adicionada sem muitas alterações.
O padrão Strategy representa uma escolha melhor em situações onde a classe Com-
ponent é intrinsecamente pesada, dessa forma tornando a aplicação do padrão Decorator
muito onerosa. No padrão Strategy, o componente repassa parte do seu comportamento para um objeto strategy separado, além de permitir alterar ou estender a funcionalidade do componente pela substituição do objeto strategy.
2.6.3
O padrão Data Access Object (DAO)
Aplicativos usam a API JDBCpara acesso a dados persistentes, permitindo acesso pa- drão para manipulação dos dados através do uso de instruções SQL. No entanto, a sin- taxe dos comandos SQL pode variar, dependendo do fabricante. Essa dependência torna difícil e tediosa a migração de uma fonte de dados para outra. Quanto às alterações nas fontes de dados, os componentes precisam ser mudados para lidar com a nova fonte de
2.6. PADRÕES DE PROJETO
dados. Uma forma de contornar esse tipo de problema é utilizar o padrão DAO para abstrair e encapsular todo o acesso à fonte de dados (DAO,2010).
DAOimplementa um mecanismo para acesso as diversas fontes de dados. O compo- nente de negócio que se baseia noDAOusa uma interface simples que oculta completa- mente os detalhes da fonte de dados em execução. Como a interface exposta peloDAO
para os clientes não se altera quando há mudanças na implementação do código, esse padrão permite que o DAOpossa se adaptar a diferentes esquemas de armazenamento sem afetar seus clientes ou os componentes do negócio. Essencialmente, o DAO age como um adaptador entre o componente e a fonte de dados.
O padrão DAOfornece uma interface independente, na qual pode-se usar para per- sistir objetos de dados. A ideia é colocar todas as funcionalidades de acesso e trabalho com os dados em um só local, tornando simples sua manutenção. Tipicamente umDAO
inclui métodos para inserir, selecionar, atualizar e excluir objetos de um banco de dados. Dependendo de como se implementa o padrão DAO, pode-se ter um DAO para cada classe de objetos na aplicação, ou podera-se ter um únicoDAOresponsável por todos os objetos (Gonçalves,2007). A Figura2.11mostra o diagrama de classe que representa as relações para o padrão DAO (DAO,2010).
Figura 2.11 Diagrama do Padrão DAO (DAO,2010)
2.6.4
O padrão Model View Controller (MVC)
MVCé um conceito de desenvolvimento e design que tenta separar uma aplicação em três partes distintas. A primeira, o modelo, está relacionada ao trabalho atual que a aplicação administra, outra parte, a visão, está relacionada com a exibição dos dados ou