Design Pattern
(Padrões de Projeto)
Prof. Alexandre Monteiro
Recife
‹#›
Contatos

Prof. Guilherme Alexandre Monteiro Reinaldo

Apelido: Alexandre Cordel

E-mail/gtalk: [email protected]
[email protected]

Site: http://www.alexandrecordel.com.br/fbv

Celular: (81) 9801-1878
Origem Padrão de Projeto

Christopher Alexander em seus livros (1977/1979) Notes on the Synthesis
of Form, The Timeless Way of Building e A Pattern Language, estabelece
que um padrão deve ter, idealmente, as seguintes características:
• Encapsulamento: um padrão encapsula um problema ou solução bem definida. Ele deve
ser independente, específico e formulado de maneira a ficar claro onde ele se aplica.
• Generalidade: todo padrão deve permitir a construção de outras realizações a partir
deste padrão.
• Equilíbrio: quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão,
relacionada com cada uma das restrições envolvidas, para cada passo do projeto. Uma
análise racional que envolva uma abstração de dados empíricos, uma observação da
aplicação de padrões em artefatos tradicionais, uma série convincente de exemplos e uma
análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio.
• Abstração: os padrões representam abstrações da experiência empírica ou do
conhecimento cotidiano.
• Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.
• Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível
podem ser compostos ou relacionados com padrões que endereçam problemas de nível
mais baixo.
Características de Padrão de Projeto

Alexander definiu que um padrão deve ser descrito em cinco
partes:
• Nome: uma descrição da solução, mais do que do problema ou do
contexto.
• Exemplo: uma ou mais figuras, diagramas ou descrições que ilustrem um
protótipo de aplicação.
• Contexto: a descrição das situações sob as quais o padrão se aplica.
• Problema: uma descrição das forças e restrições envolvidos e como elas
interagem.
• Solução: relacionamentos estáticos e regras dinâmicas descrevendo como
construir artefatos de acordo com o padrão, freqüentemente citando
variações e formas de ajustar a solução segundo as circunstâncias. Inclui
referências a outras soluções e o relacionamento com outros padrões de
nível mais baixo ou mais alto.
Introdução à Padrão de Projeto



É uma solução geral reutilizável para um problema que ocorre
com frequência dentro de um determinado contexto no
projeto de software.
Um padrão de projeto não é um projeto finalizado que pode
ser diretamente transformado em código fonte ou de máquina,
ele é uma descrição ou modelo (template) de como resolver
um problema que pode ser usado em muitas situações
diferentes.
Padrões são melhores práticas formalizadas que o programador
pode usar para resolver problemas comuns quando projetar
uma aplicação ou sistema.
Introdução à Padrão de Projeto


Padrões de projeto orientados a objeto normalmente
mostram relacionamentos e interações entre classes ou
objetos, sem especificar as classes ou objetos da
aplicação final que estão envolvidas.
Padrões que implicam orientação a objetos ou estado
mutável mais geral, não são tão aplicáveis em linguagens
de programação funcional.
Padrão GoF



Livro Design Patterns: Elements of Reusable Object-Oriented Software,
publicado em 1995.
Autores: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides,
são conhecidos como a "Gangue dos Quatro" (Gang of Four) ou
simplesmente "GoF".
Os padrões "GoF" são organizados em 3 famílias :
• Padrões de criação: relacionados à criação de objetos
• Padrões estruturais: tratam das associações entre classes e objetos.
• Padrões comportamentais: tratam das interações e divisões de
responsabilidades entre as classes ou objetos.

Padrão "GoF" é classificado em 2 outros grupos :
• Padrões com escopo de classe : definido por relacionamentos de herança e
em tempo de compilação.
• Padrões com escopo de objeto : encontrados no relacionamento entre os
objetos definidos em tempo de execução.
Alguns Padrões de Projeto

Padrões de criação
• Abstract Factory | Builder | Factory Method | Prototype | Singleton

Padrões estruturais
• Adapter | Bridge | Composite | Decorator | Façade (ou Facade) |
Flyweight | Proxy

Padrões comportamentais
• Chain of Responsibility | Command | Interpreter | Iterator | Mediator |
Memento | Observer | State | Strategy | Template Method | Visitor

Utilizaremos em nosso projeto 2 desses padrões:
• Facade e Singleton
Facade ou Fachada

É um objeto que disponibiliza uma interface simplificada
para uma das funcionalidades de uma aplicação.
Singleton


Este padrão garante a existência de apenas uma instância
de uma classe, mantendo um ponto global de acesso ao seu
objeto.
Ex.: Conexão com banco de dados, Log de sistema, Sessão
de Aplicação, etc.
Fachada + Singleton
Browser
Evolução dos Dados
(DADOS)
MODEL
(Objeto)
MODEL
(Objeto)
Mapeamento
Objeto-Relacional
TABELA
(Registro)
Linguagens
(VIEW)
JSP
Fachada
(CONTROLLER)
(MODEL)
HIBERNATE
JAVA
JAVA
HQL
SQL
Fachada + Singleton
Fachada
Singleton
Continuação: Fachada + Singleton
Controlador

Deverá ser criado um pacote “controlador” ou “controller”,
no qual deverá constar um conjunto de classes de controle
referentes a cada uma da Entidades manipuladas para o
projeto.
Controlador
Controlador: saveUsuario(u)
Controlador: deleteUsuario(u)
Controlador: updateUsuario(u)
Controlador: listUsuarios()
Controlador: searchUsuario_(...)
Exception

Deverá ser criado um pacote “exception”, no qual deverá
constar um conjunto de classes de exceções referentes a
cada uma da Entidades manipuladas para o projeto.
DAO (Data Access Object)

Objetivo
• Prover isolamento da tecnologia de persistência.

Propósito
• O padrão Data Access Object (DAO) é um padrão
introduzido no ambiente JEE [3] para simplificar e
desacoplar a interação das aplicações Java com a API
JDBC.
DAO (Data Access Object)

O problema que o padrão DAO tenta resolver tem, na
realidade, três perspectivas:
• Legado: Queremos encapsular lógicas de persistência legadas escritas
com SQL ou outras tecnologias de forma simples. Queremos apenas
utilizar as tecnologias java, mas manter as mesmas regras de negócio.
• Isolamento: Queremos que a aplicação seja isolada da API com que
está comunicando. Queremos poder alterar a API utilizada
internamente sem alterar o contrato de acesso aos dados.
• Mapeamento de Objetos: Queremos utilizar objetos no ambiente
Java. Queremos poder utilizar os mesmos objetos independentemente
da API de persistência. Normalmente isto passa por respeitar algum
Mapeamento Objeto-Relacional - ORM (Object-Relational Mapping).
DAO (Data Access Object)


A principal vantagem do DAO é ter um local onde
todo o acesso a dados será concentrado, ao invés
de ter várias classes que manipulam dados
espalhadas pela aplicação.
A desvantagem é acrescentar mais uma camada
(interface), aumentar o nível de complexidade,
ficar um pouco mais pesado por ter que instanciar
mais classes.
DAO (Data Access Object)

A interface do padrão original é simples. São fornecidos métodos para
as operações CRUD, sendo que a operação de recuperação é distribuída
em diferentes métodos de pesquisa especializados. São estes métodos
especializados que encapsulam facilmente lógicas de pesquisa de
sistemas legados.
DAO (Data Access Object)
DAO Genérico