Guia de Design Patterns e Persistência de Dados em Java

Statement e PreparedStatement: representam um comando SQL a ser executado.

ResultSet: representa os dados obtidos como resultado de uma consulta no banco de dados Select.

Data Access Object (DAO): padrão para persistência de dados que permite separar regras de negócio das regras de acesso ao banco de dados.

Problema: código de acesso a banco de dados misturado com regras de negócio.

Solução: criar um ponto de acesso central em um pequeno conjunto de classes que serão responsáveis por acessar os dados da aplicação; separar a classe de negócio das classes de acesso a dados.

Design Patterns

Design Patterns: é uma técnica de modelagem de classes e objetos que resolve um problema comum a diversos tipos de aplicativos.

Princípios de Design: programe para interface, não para implementação; prefira a composição de dados de objetos à herança de classe; encapsule o que variar.

Quando a herança é utilizada apropriadamente, todas as classes derivadas sobrescrevem os métodos da sua superclasse. Não declare variáveis como instâncias de classes concretas, mas para classes abstratas ou interfaces. A interface representa uma abstração do comportamento de uma ou mais classes.

Vantagem da herança: é definida estaticamente em tempo de execução; é simples de usar, uma vez que é suportada pela linguagem; torna mais fácil modificar a implementação que está sendo reutilizada.

Desvantagem: as superclasses definem parte da representação física das suas subclasses; certos aspectos herdados podem não fazer sentido em determinados contextos.

Olhar para uma classe, enxergar suas responsabilidades, abstrair suas possíveis alterações e criar uma nova classe. Se a classe precisar ter mais de uma responsabilidade, divida-as e as associe.

Chain of Responsibility

Objetivo: Definir objetos que podem receber uma solicitação ao longo de uma cadeia. O primeiro objeto na cadeia que recebe a solicitação pode tratar a mesma ou repassar para o próximo candidato na cadeia.

O objeto que faz a solicitação não tem conhecimento explícito de quem tratará a requisição; desta forma, dizemos que a solicitação tem um receptor implícito.

A Chain of Responsibility tem os seguintes benefícios e deficiências:

• Acoplamento reduzido: O padrão libera um objeto de ter que conhecer qual o outro objeto que trata de uma solicitação. Tanto o receptor como o remetente não têm conhecimento explícito um do outro, e um objeto que está na cadeia não necessita conhecer a estrutura da mesma.
• Flexibilidade adicional na atribuição de responsabilidades a objetos: É possível acrescentar ou mudar responsabilidades para tratamento de uma solicitação pelo acréscimo ou mudança da cadeia em tempo de execução.
• A recepção não é garantida: Uma vez que uma solicitação não tem um receptor explícito, não há garantia de que ela será tratada. A solicitação pode sair pelo final da cadeia sem ter sido tratada.

Conclusões

Para repassar a solicitação ao longo da cadeia e para garantir que os receptores permaneçam implícitos, cada objeto na cadeia compartilha uma interface comum para o tratamento da solicitação e para acessar seu sucessor na cadeia.

Patterns Factory Method e Command

Os padrões Factory Method e Command são aplicados para a elaboração de uma classe controladora (Servlet). Podemos, de forma simples, entender Design Patterns como uma maneira de organizar suas classes diante de determinada circunstância.

Popularmente, as principais categorias de Design Patterns utilizados com Java e J2EE são:

1. GoF (Gang of Four) Patterns: são mais antigos e utilizados com Smalltalk, C++, Java, entre outras linguagens. Singleton, Factory Method, Memento, Proxy, Adapter, Iterator, Observer e muitas outras fazem parte dos patterns GoF.
2. Patterns J2EE: são mais focados em problemas com os padrões de arquitetura e uma forma de componentização imposta pela plataforma Java 2 Enterprise Edition.

De uma maneira geral, podemos afirmar que os diversos Design Patterns, apesar de servirem para resolver problemas distintos, acabam todos com o objetivo comum de buscar por:

• Código menos extenso possível;
• Código mais legível possível;
• Código mais flexível possível;
• Divisão de responsabilidades entre os objetos;
• Aplicação do conceito de reutilização de objeto.

Pattern Command: é bastante aplicado em frameworks de interface gráfica e web. Aplicamos o Command para encapsular ações que geralmente estão associadas a um objeto de interface gráfica, como, por exemplo, um botão.

Na web, podemos lembrar do framework Jakarta Struts, que encapsula cada ação da web em uma subclasse denominada Action. Por este motivo, se você já utilizou AWT, Swing ou Struts, com certeza já foi usuário deste pattern.

Um dos Design Patterns popularmente utilizado em conjunto com o Command é o Factory Method. Factories são classes responsáveis por criar objetos de uma determinada hierarquia através de um sistema de vínculo fraco, que permite a adição de novas classes Command sem alteração das classes que a utilizam.

Quando temos uma hierarquia de classes definida, fatalmente temos a necessidade de criar as subclasses conforme um determinado comando que foi acionado. O ideal é que o vínculo esteja apenas com a classe de base Command, como a interface ICommand, e não com suas demais classes. Com isso, poderíamos pensar que a criação de um novo comando não acarretaria na alteração de nossa Servlet, por exemplo, facilitando a extensibilidade da aplicação.

Uma das grandes vantagens de trabalhar com Factory é que podemos controlar o ciclo de vida, a quantidade de objetos e também podemos fazer sistemas de cache e pooling. A grande maioria dos frameworks Java para diversas disciplinas trabalham com Factory para garantir o reaproveitamento de objetos e evitar a construção e destruição excessiva de objetos, operações que apresentam um alto custo para a máquina frente a uma grande demanda.

Design Pattern J2EE – Front Controller

Cada Servlet e JSP será um potencial ponto de acesso ao seu aplicativo. A centralização das regras de atendimento às requisições dos usuários tem a intenção de promover maior facilidade no controle de requisições, que poderão ser complexas e contínuas, necessitando de diversos serviços comuns.

Padrões de Projetos Estruturais

Composite: compor objetos em estrutura de árvores para representarem hierarquias todo-parte. O Composite permite tratar de maneira uniforme objetos individuais e composições de objetos. Tipicamente, modelos Composite trabalham com sistemas de nós que são chamados de árvores. Em uma árvore de objetos, podemos ter nós e nós do tipo folha, que não podem conter outros nós.

Builder: propõe que o processo de construção de um objeto, quando complexo, seja separado da definição do objeto, para que possamos ter diferentes tipos de algoritmos de construção, permitindo diferentes representações para o objeto.

O padrão Factory trabalha na criação de objetos de uma família de classes, utilizando intensamente o polimorfismo, enquanto o Builder tem o foco nos detalhes de construção de uma instância de objeto que não necessariamente terá uma família de subclasses.

Filtro de Intercepção

É um recurso da Servlet 2.3 ou posterior, que permite que as requisições que chegam a um servidor (como o Tomcat) sejam interceptadas por uma classe Java comum, que pode realizar qualquer tipo de processamento e autorizar a requisição ou cancelá-la. Exemplo: redirecionar o usuário para algum recurso ou página.