Padrões de Design
Toacy Cavalcante de Oliveira
Problema
November 5, 2015
2
Análise vs Projeto

Análise
 Modela
o mundo real.
 Usualmente não é “mapeável”para o Projeto
pois tende a ser ineficiente/ineficaz.

Projeto
 Atribuição
de Responsabilidades.
 Boas práticas (+Coesão, -Acoplamento)
November 5, 2015
3
Como compatibilizar os dois
mundos?
Tipicamente, bons projetistas são
formados após um longo período de
experiência.
 São hábeis praticantes do conceitos
básicos de ES.

 Abstração,
November 5, 2015
Flexibilidade e Modularidade
4
Problema

Como capturar este conhecimento de
modo a transmiti-lo a outros
desenvolvedores para que estes também
se tornem experts?

Design Patterns
November 5, 2015
5
Introdução
November 5, 2015
6
Definições

“um padrão descreve um problema que se
repete várias vezes em um determinado
meio, descrevendo o núcleo de sua
solução, de modo que esta solução possa
ser usada milhares e milhares de vezes."
[Christopher Alexander]
November 5, 2015
7
Definições

Os Padrões de Design formam um
conjunto de regras que descrevem como
realizar certas tarefas no âmbito do
desenvolvimento de software [Pree, 1994].
November 5, 2015
8
Definições


Um Padrão de Design visa resolver um
problema recorrente de design que surge em
determinadas situações [Buschmann et al.,
1996].
Os Padrões de Design identificam e definem
abstrações que estão acima do nível de uma
única classe e de suas instâncias, ou de
componentes [Gamma et al., 1994].
November 5, 2015
9
Motivação para DP
Novos problemas são geralmente
similares a problemas já resolvidos
anteriormente.
 As soluções para problemas similares
seguem padrões recorrentes.

November 5, 2015
10
Benefícios




Servem de guia para a solução do problema.
Ajudam a gerenciar a complexidade do software
Estimulam a aplicação e disseminação de boas
práticas da POO.
Definem um vocabulário comum entre os
projetistas, o que ajuda na disseminação de
soluções bem sucedidas.
November 5, 2015
11
Histórico
November 5, 2015
12
De onde vêm?

Christofer Alexander
A
Pattern Language, Oxford University Press 1977
 Timeless way of Building, Oxford University Press
1979

C.A. era arquiteto e identificou uma série de
padrões utilizados na construção de edificações.
November 5, 2015
13
OOPSLA

Em 1987, Ward Cunningham e Kent Beck
usaram algumas das idéias de Alexander
no trabalho sobre GUI intitulado “Using
Pattern Languages for Object-Oriented
Programs” [OOPSLA-87].
November 5, 2015
14
Gang-of-Four

Em 1994, Erich Gamma, Richard Helm,
John Vlissides e Ralph Johnson
publicaram um dos livros mais importantes
de Engenharia de Software da década de
90: “Design Patterns: Elements of
Reusable Object-Oriented Software”
[GoF].
November 5, 2015
15
Livros
Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Addison-Wesley, October 1994
November 5, 2015
16
Descrevendo
Padrões
November 5, 2015
17
4 Elementos Essenciais

Nome do padrão

Problema

Solução

Conseqüências
November 5, 2015
18
Nome
 Serve
de referência para o
padrão.
 Aumenta o vocabulário de
projeto.
 Deve ser único.
November 5, 2015
19
Problema
 Quando
aplicar um padrão.
 Contexto.
 Lista de condições que
justifiquem aplicar o padrão.
November 5, 2015
20
Solução
 Elementos
que compõem o
padrão.
 “Arranjo” geral dos seus
elementos.
 Responsabilidades e
colaborações destes elementos.
November 5, 2015
21
Conseqüência
 Análises
 Vantagens
/ desvantagens
 Flexibilidade, capacidade de
extensão ou portabilidade.
November 5, 2015
22
Exemplo
November 5, 2015
23
Identificação




Nome: Observer
Problema: Notificar a ocorrência de um evento a
uma lista de objetos.
Solução: Observers delegam a responsabilidade
de monitoramento para um objeto central o
Subject.
Consequencias: Permite variar Subject e
Observer de forma independente. Permite
comunicação broadcast.
November 5, 2015
24
Observer - Elementos
November 5, 2015
25
Catálogo
November 5, 2015
26
GoF & POSA

GoF (“the gang of four”) catalogue
 “Design
Patterns: Elements of Reusable
Object Oriented Software,” Gamma, Helm,
Johnson,Vlissides, Addison-Wesley, 1995

POSA catalogue
 Pattern-Oriented
Software
Architecture,Buschmann, et al.; Wiley, 1996
November 5, 2015
27
Estrutura do Catálogo

Classifica padrões de acordo com seu
propósito,
 De
Criação
 Estrutural
 Comportamental

e escopo.
 Objeto
 Classe
November 5, 2015
28
Quanto ao escopo

Classes
 Padrões
tratam do relacionamento entre
classes e subclasses;

Objetos
 Padrões
tratam relacionamentos entre
objetos e por isso podem ser alterados em
tempo de execução.
November 5, 2015
29
De Criação

Diz respeito ao processo ou ciclo de
criação de um objeto.
 Escopo
classe: delega a criação de um objeto
para alguma de suas subclasses.
 Escopo
objeto: delega a criação de um objeto
para outro objeto
November 5, 2015
30
Estrutural

Diz respeito a composição de objetos e
classes;
 Escopo
classe: Utilizam herança para compor
objetos
 Escopo
Objeto: Descreve formas de compor
objetos.
November 5, 2015
31
Comportamental

Caracteriza o modo como classes e
objetos interagem e compartilham
responsabilidades.
 Escopo
Classe: Utiliza herança para
descrever algoritmos e controle de fluxo.
 Escopo Objeto: Descreve como um grupo de
objetos cooperam de modo a executar uma
tarefa.
November 5, 2015
32
Visão Geral
Escopo
Class
Object
November 5, 2015
Criação
Factory Method
Abstract Factory
Builder
Prototype
Singleton
Propósito
Estrutural
Adapter (classe)
Adapter (object)
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Comportamental
Interpreter
Template Method
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
33
Estrutura Interna

Além das 4 características essenciais, o
Catálogo do GoF define outras
características para descrever padrões.
November 5, 2015
34
Estrutura Interna 1/3

Nome do Padrão e Classificação


Propósito



O quê o Padrão faz?
Que tipo de problema ou característica particular de projeto ele trata?
Também Conhecido Como:


Passa a fazer parte do vocabulário dos projetistas.
Conjunto de outros nomes (apelidos) conhecidos para o Padrão, se existir
algum.
Motivação

Um cenário que ilustra o problema de projeto e como as estruturas de classes e
objetos no Padrão o resolvem.
November 5, 2015
35
Estrutura Interna 2/3

Aplicação




Estrutura


Uma representação gráfica das classes no padrão
Participantes


Quais são as situações onde este padrão pode ser aplicado?
Quais são os exemplos de projetos que ele pode tratar?
Como você pode reconhecer estas situações?
As classes e/ou objetos que participam no padrão de projeto, e suas
responsabilidades
Colaborações

Como os participantes interagem para cumprir suas responsabilidades
November 5, 2015
36
Estrutura Interna 3/3

Conseqüências



Implementação


Fragmentos de código que ilustram como o padrão deve ser implementado
Usos Conhecidos


Dicas e técnicas que o projetista deve saber, e possíveis armadilhas para as quais ele deve
estar preparado.
Exemplo de Código


Como o padrão alcança seus objetivos?
Quais são os resultados do uso do padrão?
Exemplos de utilização do padrão em sistemas já implementados.
Padrões Relacionados

Lista de alguns padrões fortemente relacionados ao padrão em questão e as suas
principais diferenças.
November 5, 2015
37
Observer
November 5, 2015
38
O padrão Observer

Classificação
 Comportamental

de Objetos
Propósito
 Provê
sincronização, coordenação e consistência
entre objetos relacionados.

Também Conhecido Como:
 Dependents,
November 5, 2015
Publish-Subscribe
39
Motivação

Necessidade de manter consistência entre objetos relacionados.

Não existe interesse em tornar as classes fortemente acopladas.

Ex. Planilha e gráfico de barras.


Não tem conhecimento um do outro
Trabalham em conjunto apresentando uma mesma informação

O padrão observer oferece um mecanismo para resolver esse problema

Subject Possui um conjunto de observers.

Notifica seus observers quando sofre uma mudança de estado
November 5, 2015
40
Aplicabilidade

Quando uma mudança em um objeto
exige mudanças em outros, e não são
conhecidos quantos devem ser mudados.

Quando um objeto deve ser capaz de
notificar outros objetos sem que estes
sejam fortemente acoplados.
November 5, 2015
41
Estrutura
November 5, 2015
42
Participantes

Subject



ConcreteSubject



guarda o estado de interesse para ConcreteObserver
envia uma notificação para seu Observer quando seu estado muda.
Observer


conhece seu Observer. Qualquer número de objetos Observer podem observar um Subject
provê uma interface para acoplar e desacoplar objetos Observer.
define uma interface de atualização para objetos que devem ser notificados sobre mudanças em um
Subject.
ConcreteObserver



Mantém uma referência para um objeto ConcreteSubject
Guarda o estado que deve ficar consistente com o de Subject
Implementa o Observer atualizando a interface para manter seu estado consistente com o de
Subject.
November 5, 2015
43
Colaborações

O ConcreteSubject notifica seus
observadores sempre que ocorrer uma
mudança.

Após ter sido notificado, um
ConcreteObserver pode consultar o
subject.
November 5, 2015
44
Conseqüências

Acoplamento fraco entre o Subject e o
Observer

Suporte para comunicações em broadcast

Atualizações inesperadas
November 5, 2015
45
Implementação

Observando mais de um subject
 Subject
ativador é passado como parâmetro
no método update()

Quem dispara a atualização?
 Subject
 Cliente
November 5, 2015
46
Exemplo de código
November 5, 2015
47
Exemplo de código
November 5, 2015
48
Exemplo de código
November 5, 2015
49
Usos conhecidos

Serviço de Eventos e Serviço de
Notificação (CORBA)
November 5, 2015
50
Padrões relacionados

Mediator
 Encapsula
a semântica de atualizações complexas, o
ChangeManager atua como um mediador entre
subjects e observers

Singleton
o
ChangeManager pode usar o padrão singleton para
torná-lo único e globalmente acessível.
November 5, 2015
51
Catálogo
November 5, 2015
52
Catálogo

Abstract Factory:


Adapter:


Separa uma abstração de sua implementação, de modo que ambas possam variar
independentemente.
Builder:


Converte a interface de uma classe em outra, esperada pelo cliente. O Adapter permite que classes
que antes não poderiam trabalhar juntas, por incompatibilidade de interfaces, possam agora fazê-lo.
Bridge:


Provê uma interface para criação de famílias de objetos relacionados ou interdependentes. Remove
a dependência entre o cliente, que usa os objetos, e a classe dos objetos produzidos.
Provê uma interface genérica para a construção incremental de agregações. Um Builder esconde os
detalhes de como os componentes são criados, representados e compostos.
Chain of Responsibility:

Encadeia os objetos receptores e transporta a mensagem através da corrente até que um dos
objetos a responda. Assim, separa (provê loose coupling) objetos transmissores dos receptores,
dando a chance de mais de um objeto poder tratar a mensagem.
November 5, 2015
53
Catálogo de Padrões de Projeto

Command:


Composite:


Anexa responsabilidades adicionais a um objeto dinâmicamente. Provê uma alternativa
flexível para extensão de funcionalidade, sem ter que usar Herança.
Facade:


Compõe objetos em árvores de agregação (relacionamento parte-todo). O Composite
permite que objetos agregados sejam tratados como um único objeto.
Decorator:


Encapsula uma mensagem como um objeto, de modo que se possa parametrizar
clientes com diferentes mensagens. Separa, então, o criador da mensagem do executor
da mesma.
Provê uma interface unificada para um conjunto de interfaces em um subsistema. O
Facade define uma interface alto nível para facilitar o uso deste subsistema.
Factory Method:

Define uma interface para criação de um objeto, permitindo que as suas subclasses
decidam qual classe instanciar. O Factory Method deixa a responsabilidade de
instanciação para as subclasses.
November 5, 2015
54
Catálogo

Flyweight:


Interpreter:


Provê um modo de acesso a elementos de um agregado de objetos, sequencialmente,
sem exposição de estruturas internas.
Mediator:


Usado para definição de linguagem. Define representações para gramáticas e
abstrações para análise sintática.
Iterator:


Usa o compartilamento para dar suporte eficiente a um grande número de objetos com
alto nível de granularidade.
Desacopla e gerencia as colaborações entre um grupo de objetos. Define um objeto
que encapsula as interações dentre desse grupo.
Memento:

Captura e externaliza o estado interno de um objeto (captura um "snapshot"). O
Memento não viola o encapsulamento.
November 5, 2015
55
Catálogo

Observer:


Prototype:


Provê Design para um controlador de acesso a um objeto.
Singleton:


Especifica os tipos de objetos a serem criados num sistema, usando uma
instância protótipo. Cria novos objetos copiando este protótipo.
Proxy:


Provê sincronização, coordenação e consistência entre objetos relacionados.
Assegura que uma classe tenha apenas uma instância e provê um ponto
global de acesso a ela.
State:

Deixa um objeto mudar seu comportamento quando seu estado interno muda,
mudando, efetivamente, a classe do objeto.
November 5, 2015
56
Catálogo

Strategy:


Template Method:


Define uma família de algoritmos, encapsula cada um deles, e torna a escolha
de qual usar flexível. O Strategy desacopla os algoritmos dos clientes que os
usa.
Define o esqueleto de um algoritmo em uma operação. O Template Method
permite que subclasses componham o algoritmo e tenham a possibilidade de
redefinir certos passos a serem tomados no processo, sem contudo alterar sua
inetrface.
Visitor:

Representa uma operação a ser realizada sobre elementos da estrutura de um
objeto. O Visitor permite que se crie um nova operação sem que se mude a
classe dos elementos sobre as quais ela opera.
November 5, 2015
57
Utilização
November 5, 2015
58
Como utilizar Padrões?

Existem algumas perguntas que auxiliam
o emprego de Design Patterns.

A resposta não é exata mas da uma boa
direção!
November 5, 2015
59
Variação

Existe variação de uma regra de negócio
ou implementação?
 Strategy
 Bridge
 Proxy
 Decorator
 Visitor
November 5, 2015
60
Ex. Strategy

Existe alguma variação na regra?
 Define
uma família de algoritmos, encapsula
cada um deles, e torna a escolha de qual
usar flexível. O Strategy desacopla os
algoritmos dos clientes que os usa.

Ex. Feature Alternativas são candidatas para o
Strategy.
November 5, 2015
61
Interfaces

Existe uma preocupação com interfaces
e/ou tratamento de “objetos”
incompatíveis?
 Adapter
 Composite
 Facade
November 5, 2015
62
Ex. Facade

Existe a necessidade de simplificar, “OOificar” uma classe ou um subsistema?
 Provê
uma interface unificada para um
conjunto de interfaces em um subsistema. O
Facade define uma interface alto nível para
facilitar o uso deste subsistema.
November 5, 2015
63
Desacoplamanto

Existe a necessidade de desacoplar ?
 Observer
 Chain
of Responsibility
 Iterator
 Mediator
 State
November 5, 2015
64
Ex. State

Existem objetos om muitos estados,
implicando e um difícil gerenciamento
destes (muito código) ?
 Deixa
um objeto mudar seu comportamento
quando seu estado interno muda, mudando,
efetivamente, a classe do objeto.
November 5, 2015
65
Criação

Existe a necessidade de criar coisas?
 Abstract
Factory
 Builder
 Factory
November 5, 2015
Method
66
Ex. Factory Method

As subclasses necessitam saber/descobrir
o que instanciar?
 Define
uma interface para criação de um
objeto, permitindo que as suas subclasses
decidam qual classe instanciar. O Factory
Method deixa a responsabilidade de
instanciação para as subclasses.
November 5, 2015
67
Mais sobre
Padrões
November 5, 2015
68
+Padrões

Analysis patterns –

Soluções típicas para problemas de análise recorrente.
 Analysis Patterns, Fowler; Addison-Wesley, 1996
 Applying UML and Patterns, Larman, Prentice-Hall, 1998

Architectural patterns


Veja POSA
Idioms




Smalltalk Best Practice Patterns, Beck; Prentice Hall, 1997
Concurrent Programming in Java, Lea; Addison-Wesley, 1997
Advanced C++, Coplien, Addison-Wesley, 1992
Effective C++: 50 Specific Ways to Improve Your Programs and Design
(2nd Edition), Scott Meyers, Addison-Wesley, (September 1997)
 More Effective C++: 35 New Ways to Improve
November 5, 2015
69
Anti-Patterns

Soluções de projeto que não respeitam as
regras de bons procedimentos em ES.
 Abstração,

Flexibilidade e Modularidade
http://www.antipatterns.com
November 5, 2015
70
From http://www.antipatterns.com/briefing/sld006.htm
Anti-Patterns
November 5, 2015
71
Referências Adicionais
Apostila do Prof. Ivan (no site)
 Design Patterns Explained: A New
Perspective on Object-Oriented Design,
Alan Shalloway, James R. Trott,
 http://www.netobjectives.com/dpexplained/
download/dpmatrix.pdf

November 5, 2015
72