Padrões de Projeto

Padrões de Projeto
Prof. Jefersson Alex dos Santos ([email protected])
http://www.dcc.ufmg.br/~jefersson
Apresentação
 Conceitos
–
–
Definição
Ponto de vista prático
 História
 Padrões de Projeto Conhecidos
–
–
Padrões GoF
Outros Padrões
 Aplicações (JFC e SEAD)
 Conclusão
Conceitos
 Segundo o dicionário Aurélio:
–
Padrão sm. 1. Modelo oficial de
pesos e medidas. 2. O que serve de
base ou norma para avaliação,
medida. 3. Objeto que serve de
modelo à feitura de outro. 4. Desenho
decorativo estampado em tecido ou
outra superfície.
Conceitos
 Para a Engenharia de Software:
–
–
Um padrão é uma combinação
recorrente de elementos de
modelagem que ocorrem em algum
contexto;
Padrões podem ser aplicados nas
diversas etapas do desenvolvimento
de software.
Conceitos
 Fases de Desenvolvimento de
Software:
Ciclo de vida clássico
Padrões de Análise
 Um padrão de análise é qualquer
parte de uma especificação de
requisitos que se origina em um
projeto e pode ser reutilizada em
diversos projetos.
Padrões de Análise
 Exemplo:
–
Padrão para reservas e locação de
entidades reutilizáveis (quarto de
hotel, aluguel de automóveis, filmes,
etc).
Padrões de Projeto
 Os padrões de projeto são
arquiteturas comprovadas para
construir software orientado a
objetos;
 A idéia é a mesma dos padrões de
projeto aplicadas na arquitetura.
Padrões: Análise X Projeto
 Padrões de análise são
dependentes da aplicação.
Descrevem aspectos típicos de
algum domínio ou aplicação;
 Padrões de projeto estão mais
próximos da implementação. Focam
interfaces, criação de objetos e
propriedades estruturais.
Framework X Padrões
 Atenção:
–
–
Padrões de Projeto e frameworks
são coisas diferentes;
Frameworks são estruturas de
suporte bem definidas em que um
outro projeto de software pode ser
organizado e desenvolvido .
Ponto de Vista Prático
 Padrões de projeto não são
algoritmos;
 Padrões de projeto não oferecem
componentes;
 Padrões de projeto oferecem
soluções comprovadamente
eficientes;
 Catálogos de Padrões funcionam
como “Livros de Receitas”.
Ponto de Vista Prático
 Software:
Bolo de Chocolate
Ponto de Vista Prático
 Catálogos de Padrões de Projeto:
Livros de Receitas
Ponto de Vista Prático
 Framework:
“Bolo de Caixinha”
Design Patterns: FAQs
 Pra que serve?
 Por que utilizar?
 Compensa?
 Quais as vantagens?
 Quem deve utilizar?
 Como surgiram?
 Existem aplicações bem
sucedidas?
Design Patterns: Vantagens
 Segundo Deitel & Deitel:
–
–
–
–
–
Ajudam a construir software
confiável com arquiteturas
comprovadas;
Promovem reutilização de projeto;
Ajudam a identificar erros e
armadilhas comuns;
Estabelecem um vocabulário comum
entre os desenvolvedores;
Encurtam a fase de projeto.
Design Patterns: História
 Década de 1980:
–
–
–
–
Linguagem OO: SmallTalk;
C++ “engatinhava”;
Programação de Frameworks era
bastante popular;
Alguns frameworks, que hoje
chamados de padrões, surgiram.
Exemplo: MVC.
Design Patterns: História
 Década de 1990:
–
–
–
Linguagens OO: C++, Java;
Primeiras formalizações;
Erich Gamma, Richard Helm, Ralph
Johnson e John Vlissides
escreveram:
●
Design Patterns: Elements of Reusable
Object-Oriented Software – “The GoF
Book”.
Design Patterns: História
 Atualmente:
–
–
–
Novos projetos são criados a todo
momento;
Há muitos projetos catalogados na
Internet;
Novos conceitos relacionam-se
diretamente:
●
●
XP (eXtreme Programming –
Programação Extrema);
Refactoring (Refatoração).
Os Padrões GoF
 A “turma dos quatro” descreveu,
em seu livro, 23 padrões de
projeto;
 Esses padrões foram divididos
em três categorias:
–
–
–
Criacionais;
Estruturais;
Comportamentais.
Padrões de Criação
 Lidam com a melhor maneira de
instanciar objetos;
 O aplicativo não deve depender
de como os objetos são criados
ou arranjados;
 Abstrair o processo de criação em
uma “classe criadora” pode tornar
o software mais flexível e
genérico.
Padrões de Criação
PADRÃO
DESCRIÇÃO
Abstract Factory
É uma fábrica de objetos que
retorna outras fábricas.
Builder
Separa a construção de um objeto
complexo de sua representação.
Factory Method
Retorna uma instância dentre
muitas possíveis classes,
dependendo dos dados providos.
Prototype
Permite a um objeto devolver uma
cópia de si mesmo para um objeto
que o solicite.
Singleton
Garante que apenas uma única
instância de uma classe vai existir.
Padrões Estruturais
 Descrevem maneiras comuns de
organizar classes e objetos de um
sistema:
–
–
A herança pode ser utilizada para
tornar mais utilizáveis as interfaces
do programa;
Objetos podem ser compostos em
grandes estruturas utilizando
composição ou inclusão de objetos
dentro de outros.
Padrões Estruturais
PADRÃO
DESCRIÇÃO
Adapter
Fornece um objeto de uma nova
interface que se adapta à interface de
outro objeto.
Bridge
Permite que se criem novos
componentes para diferentes
plataformas com uma “ponte”. A
“ponte” esconde detalhes específicos
de cada plataforma.
Composite
Permite que um objeto cliente que está
percorrendo uma estrutura hierárquica
não precise determinar o tipo de cada
componente dessa estrutura.
Padrões Estruturais (cont.)
PADRÃO
Decorator
Facade
Flyweight
Proxy
DESCRIÇÃO
Permite que um objeto assuma
responsabilidades adicionais
dinamicamente.
Permite que um “objeto fachada”
forneça uma interface para os
comportamentos de um
subsistema.
Permite reduzir o número de
instâncias de um mesmo dado em
uma classe.
Permite que um objeto (Objeto
Proxy) aja como um substituto para
outro.
Padrões Comportamentais
 Oferecem estratégias
comprovadas para modelar como
os objetos colaboram uns com os
outros em um sistema;
 Sugerem comportamentos
especiais apropriados para uma
grande variedade de aplicações.
Padrões Comportamentais
PADRÃO
DESCRIÇÃO
Chain-of-Resp Permite determinar o objeto que irá
onsibility
tratar uma mensagem em situações em
que os objetos “conversam”.
Command
Permite especificar a funcionalidade
desejada uma só vez, em um objeto
reutilizável.
Interpreter
Descreve como definir uma gramática e
como utilizá-la para interpretar as
entradas.
Iterator
Permite que objetos acessem dados
individuais de qualquer estrutura de
dados, sem conhecer o comportamento
da estrutura de dados.
Padrões Comportamentais
PADRÃO
DESCRIÇÃO
Mediator
Promove o baixo acoplamento entre
duas classes fazendo com que as
trocas de mensagens entre elas sejam
realizadas por um objeto mediador.
Memento
Permite que um sistema salve o estado
de um objeto, podendo ser restaurado
posteriormente.
Observer
Permite que um mesmo objeto possua
diversas representações.
State
Perminte descrever comportamentos
para estados que um objeto possui.
Padrões Comportamentais
PADRÃO
DESCRIÇÃO
Strategy
Permite armazenar um objeto
estratégia que encapsula um algoritmo
responsável pelo comportamento da
classe.
Template
Method
Exige que todos os objetos
compartilhem um único algoritmo
definido por uma superclasse.
Visitor
Permite que sejam adicionadas novas
funcionalidades a classes existentes,
de maneira plugável, sem que haja a
necessidade de se alterar a hierarquia
das classes.
Relacionamentos
Relacionamentos (Cont.)
Outros Padrões
 Padrões Arquiteturais;
 Padrões para Programação
Paralela e Distribuída;
 Padrões J2EE;
Exemplos de Aplicação
 JFC (Java Foundation Classes):
–
–
Swing: API Gráfica do Java;
É considerada uma “obra de arte” da
linguagem orientada a objetos.
 SEAD:
–
Software Estatístico de Análise de
Desempenho Acadêmico.
Conclusões
 Os padrões de projeto são
maneiras convenientes de reusar
código orientado a objetos entre
projetos e programadores.
 A idéia é simples: catalogar
interações comuns entre objetos
que são utilizados freqüentemente
pelos programadores.
Conclusões
 Termos relacionados:
–
–
–
Programação Extrema (eXtreme
Programming);
Refatoração;
Programação Orientada a Objetos.
 Não confundir com:
–
–
Padrões de análise;
Frameworks;
Referências
 Deitel, H. M. e Deitel, P. J. Java, Como
Programar. Editora Bookman, 2003, 4ª edição,
Porto Alegre, RS.
 Horstmann, Cay S. Cornell, Gary. Core Java 2 –
Volume I (Fundamentos). Editora Makron
Books, 2001, São Paulo, SP.
 Cooper, James W. The Design Patterns: Java
Companion. IBM Thomas J. Watson Research
Center. Addison Wesley Design Patterns Series.
 Gamma, Helm, Johnson e Vlisside. Design
Patterns: Elements of Reusable Software.
Addison Wesley: 1995.