Slides usados na disciplina do curso de Especialização em Projeto e Desenvolvimento de Sistemas, da Universidade Presbiteriana Mackenzie.

1. Especialização em Projeto e Desenvolvimento de Sistemas
Padrões de Projeto
Este material não substitui a leitura da bibliografia básica
Exemplos de código são de cunho didático
Prof. MSc.Vagner Figuerêdo de Santana
1

2. Avaliação
 Exercícios
 Lista de exercícios durante a disciplina
 1 prova no último dia (nota única)
 Conceitos
 0 <= nota < 3, então E
 3 <= nota < 5, então D
 5 <= nota < 7, então C
 7 <= nota < 9, então B
 9 <= nota <= 10, então A
2

3. Conteúdo programático
 Introdução
 Padrões GRASP (General Responsibility
Assignment Software Patterns)
 Caps. 17 e 25 do livro do Craig Larman
 Padrões GoF (Gang of Four)
 Todo o livro do Gamma et al.
3

4. Introdução
Um pouco de história
 Christopher Alexander
 A Pattern Language: Towns, Buildings,
Constrution (1977)
 Gamma et al.
 Design Patterns: Elements of Reusable
Object-Oriented Software (1994)
4

5. Introdução
Um pouco de história
 Um padrão descreve
 problema que ocorre
repetidamente
 solução para esse
problema de forma que se
possa reutilizar a solução
5

6. Introdução
Por quê usar padrões?
 Aprender com a experiência dos outros
 O jargão facilita a comunicação de princípios
 Melhora a qualidade do software
 Descreve abstrações de software
 Ajuda a documentar a arquitetura
 Captura as partes essenciais de forma
compacta
6

7. Introdução
No entanto, padrões…
 não apresentam uma solução exata
 não resolvem todos os problemas de
design
 não é exclusivo de orientação a objetos
7

8. Introdução
Como selecionar um padrão?
 Entenda as soluções
 Estude o relacionamento entre os padrões
 Estude as similaridades entre os padrões
 Conheça as principais causas de retrabalho
 Considere o que pode mudar
8

9. Padrões GRASP
 Information Expert  Polymorphism
 Creator  Pure Fabrication
 Controller  Indirection
 Low Coupling  Protected Variations
 High Cohesion
9

10. Padrões GRASP
Information Expert
 Problema
A quem atribuir a responsabilidade sobre
fornecer/manter uma informação?
 Solução
 Atribuira responsabilidade ao especialista – a
classe que tem a informação necessária
10

11. Padrões GRASP
Creator
 Problema
 Quem deve ser responsável pela criação de
objetos?
 Solução: B deve ser Creator de A se
B agrega objetos de A
 B contém objetos de A
 B registra objetos de A
 B usa de maneira muito próxima objetos de A
 B tem os dados de inicialização de A 11

12. Padrões GRASP
Controller
 Problema
 Quem deve ser responsável pelo controlar os
eventos do sistema?
 Solução: uma classe que represente
O sistema como um todo
 Todo o negócio/organização
 Algo no mundo real envolvido na tarefa
12

13. Padrões GRASP
Controller – Facade Controller
 Centraliza acesso ao sistema em um
controlador
 Prós
 Centralizado
 Baixo acoplamento na interface
 Simplicidade
 Contras
 Centralizado
 Controller tem acoplamento alto
 Coesão baixa
13

14. Padrões GRASP
Controller – Role Controller
 Divide acesso ao sistema de acordo com o
papel dos usuários ou sistemas externos
 Prós
 Coesão melhora
 Descentralizado
 Reduz acoplamento do Controller
 Contras
 Pode ser mal balanceado
14

15. Padrões GRASP
Controller – Use Case Controller
 Divide acesso ao sistema de acordo os
casos de uso do sistema
 Prós
 Coesão
 Contras
 Acoplamento aumenta
 Explosão de classes
15

16. Padrões GRASP
Low Coupling
 O acoplamento (dependência entre
classes) deve ser mantido o mais baixo
possível
 Como medir acoplamento?
 Representar o diagrama de classes como um
dígrafo e computar o grau de saída
 Métrica CK – Coupling Between Objects
(CBO)
16

17. Padrões GRASP
High Cohesion
 A coesão (grau de “relacionamento” entre
as funcionalidades de uma classe) deve
ser mantida alta
 Como medir coesão?
 Acúmulo de responsabilidades
 Coesão entre nome de classes e métodos
 Métrica CK – Lack of Cohesion On Methods
(LCOM)
17

18. Padrões GRASP
Exemplo: Space Invaders
Fonte: http://www.freespaceinvaders.org/ 18

19. Padrões GRASP
Exemplo: Space Invaders
 Quem é responsável por
 Manter as coordenadas dos alienígenas?
 Manter as coordenadas das naves?
 Criar novas naves no início das fases?
 Controlar pontuação?
 Controlar movimento dos personagens?
 Lançar tiros?
19

20. Padrões GRASP
Polymorphism
 Problema
 Quem é responsável quando comportamento
varia?
 Solução
 Quando comportamentos relacionados
variam, use operações polimórficas nos tipos
onde o comportamento varia
20

21. Padrões GRASP
Pure Fabrication
 Problema
 Quem é responsável quando (você está
desesperado e) não quer violar alta coesão e baixo
acoplamento?
 Solução
 Associe um conjunto coeso de responsabilidades
para uma classe “artificial” (que não representa um
conceito do domínio do problema) tento em vista alta
coesão, baixo acoplamento e reúso
21

22. Padrões GRASP
Indirection
 Problema
 Como associar responsabilidades para evitar
acoplamento direto?
 Solução
 Useum objeto intermediário que faça
mediação entre outros componentes/serviços
22

23. Padrões GRASP
Protected Variations
 Princípio fundamental de Software Design
 Problema
 Como projetar sistemas de tal forma que variações
ou instabilidade não tenham impacto indesejado em
outros elementos?
 Solução
 Identificar pontos de variação/instabilidade e usar
uma interface (no sentido mais amplo) estável como
ponto de acesso
23

24. Métricas CK
 WMC (Weighted Methods per Class)
 DIT (Depth of Inheritance Tree)
 NOC (Number of Children)
 CBO (Coupling Between Objects)
 RFC (Response for a Class)
 LCOM (Lack of Cohesion in Methods)
24

25. Métricas CK
CBO
 Número de classes com a qual uma
determinada classe está acoplada
 Classes estão acopladas se
 métodos de uma classe usam
 métodos de outra classe
 atributos de outra classe
25

26. Métricas CK
LCOM
 Número de interseções vazias entre
métodos de uma classe
 considerando variáveis usadas
 Quanto mais métodos se “parecem” mais
coesa é a classe
 Em outras palavras, conta quantos pares
de métodos não têm “nada a ver”
26

27. Métricas CK
LCOM
 Exemplo:
 Considere uma Classe C com métodos
 M1 usando variáveis {V1} = {a, b, c, d, e}
 M2 usando variáveis {V2} = {a, b, e}
 M3 usando variáveis {V3} = {x, y, z}
 E interseção entre {V1}, {V2} e {V3}:
 {V1} ∩ {V2} = {a, b, e}
 {V1} ∩ {V3} = {}
 {V2} ∩ {V3} = {}
 Então LCOM de C = 2
27

28. Padrões GRASP
Exemplo: Tetris
28

29. GoF – Criacionais (Capítulo 3)
 Singleton
 Factory Method
 Abstract Factory
 Prototype
 Builder
29

30. GoF – Criacionais
Singleton
 Intenção: Garantir que uma classe tenha
somente uma instância e fornecer um
ponto de acesso à instancia
30

31. GoF – Criacionais
Singleton
 Estrutura:
<<singleton>>
Class A
Client - static instance : Class A
- Class A()
+ static getInstance() : Class A
31

32. GoF – Criacionais
Singleton
 Exemplo:
class Singleton{
private static Singleton instance;
private Singleton{ }
public static Singleton getInstance(){
if( instance == null )
instance = new Singleton();
return instance;
}
}
32

33. GoF – Criacionais
Singleton
 Use quando:
 Deve haver exatamente uma instância da
classe
 Deve deve ser facilmente acessível aos
clientes em um ponto de acesso bem
conhecido
33

34. GoF – Criacionais
Factory Method
 Intenção: Definir uma interface para
criação de um objeto, mas deixar as
subclasses decidirem qual classe
instanciar
34

35. GoF – Criacionais
Factory Method
 Estrutura:
<<abstract>> <<abstract>>
Creator Product
+ factoryMethod()
<<abstract>>
ConcreteCreator ConcreteProduct
creates
+ factoryMethod()
35

36. GoF – Criacionais
Factory Method
 Exemplo:
abstract class Product{
...
}
class ConcreteProductA extends Product{
...
}
class ConcreteProductB extends Product{
...
}
36

37. GoF – Criacionais
Factory Method
 Exemplo:
abstract class Creator{
public abstract Product create();
}
class ConcreteCreatorA extends Creator{
public Product create(){
return new ConcreteProductA() ;
}
}
class ConcreteCreatorB extends Creator{
public Product create(){
return new ConcreteProductB() ;
}
}
37

38. GoF – Criacionais
Factory Method
 Exemplo:
class GoFTest{
public static void main( String a[] ){
Creator c ;
// If A is needed
c = new ConcreteCreatorA() ;
// else
c = new ConcreteCreatorB() ;
Product p = c.create() ;
}
}
38

39. GoF – Criacionais
Factory Method
 Use quando:
 Uma classe não pode antecipar a classe de
objetos que precisa criar
 Uma classe deseja que suas subclasses
especifiquem os objetos que cria
39

40. GoF – Criacionais
Abstract Factory
 Intenção: Fornecer interface para criação
de famílias de objetos relacionados ou
dependentes sem especificar suas
classes concretas
40

41. GoF – Criacionais
Abstract Factory
 Estrutura:
<<abstract>>
AbstractFactory
+ createA() <<abstract>>
+ createB() <<abstract>>
ConcreteFactory1 ConcreteFactory2
+ createA() + createA()
+ createB() + createB()
41

42. GoF – Criacionais
Abstract Factory
 Use quando:
 Um sistema deveria ser independente de
como seus produtos são criados, compostos
e representados
 Um sistema deveria ser configurados com
uma ou várias famílias de produtos
 Uma família de objetos é destinada a ser
usada de maneira única
42

43. GoF – Criacionais
Prototype
 Intenção: Especificar os tipos de objetos
a serem criados usando uma instância-
protótipo. Novos objetos são criados pela
cópia desse protótipo
43

44. GoF – Criacionais
Prototype
 Estrutura:
Client Prototype
+ op() + clone()
ConcretePrototype
prototype -> clone()
+ clone()
return copy of self
44

45. GoF – Criacionais
Prototype Graphic
 Exemplo: + draw( coord )
+ clone()
GraphicTool
Staff MusicalNote
+ draw( coord ) + draw( coord )
+ clone() + clone()
WholeNote HalfNote
+ draw( coord ) + draw( coord )
+ clone() + clone()
45

46. GoF – Criacionais
Prototype
 Use quando:
 Classes a instanciar são especificadas em
tempo de execução
 Instâncias de classes podem ter poucas
combinações de estado
46

47. GoF – Criacionais
Builder
 Intenção: Separar a construção de um
objeto complexo de sua representação de
modo que o mesmo processo de
construção possa criar diferentes
representações
47

48. GoF – Criacionais
Builder
 Estrutura:
<<abstract>>
Director Builder
+ construct() + buildPart()
ConcreteBuilder
for( Object o : Collection ) Product
builder -> buildPart() + buildPart()
+ getResult()
48

49. GoF – Criacionais
Builder
 Exemplo:
class Director{
...
private Builder b ;
b = new ConcreteBuilder() ;
for( Object o : Collection )
b.buildPart( o ) ;
Product p = b.getResult() ;
...
}
49

50. GoF – Criacionais
Builder
 Exemplo:
abstract class Builder{
abstract buildPart( Part p );
}
class ConcreteBuilder extends Builder{
public Part buildPart( PartA a ){...}
public Part buildPart( PartB b ){...}
public Product getResult(){...}
// Product of A&B is returned
}
50

51. GoF – Criacionais
Builder
 Use quando:
O algoritmo para criar um objeto complexo
deveria ser independente das partes que
compõem o objeto
 O processo de construção deve permitir
diferentes representações para o objeto que é
construídos
51

52. Exercício
 Em duplas ou trios
 Aplicar padrões vistos até o momento em
 Projeto para “Radar” de fiscalização de
velocidade
 Componentes a considerar
 Sensor de presença
 Máquina fotográfica
 Central
 Outros (?)
52

53. GoF – Estruturais (Capítulo 4)
 Composite
 Decorator
 Proxy
 Adapter
 Bridge
 Facade
 Flyweight
53

54. GoF – Estruturais
Composite
 Intenção: Compor objetos em estruturas
de árvore para representarem hierarquias
do tipo todo-parte
54

55. GoF – Estruturais
Composite
 Estrutura: <<abstract>>
Component
+ op()
Client
+ add( :Component )
+ remove( :Component )
+ getChild( int )
Leaf Composite
+ op() + op()
+ add( :Component )
+ remove( :Component )
+ getChild( int ) 55

56. GoF – Estruturais
Composite
 Exemplo: <<abstract>>
Component
*
+ op()
Client
+ add( :Component )
+ remove( :Component )
+ getChild( int )
File Directory
+ op() + op()
+ add( :Component )
+ remove( :Component )
+ getChild( int ) 56

57. GoF – Estruturais
Composite
 Use quando:
 Você quer representar hierarquia de objetos
do tipo parte-todo
 Você quer que clientes tratem objetos
compostos e individuais da mesma forma
57

58. GoF – Estruturais
Decorator
 Intenção: Dinamicamente, agregar
funcionalidades a um objeto
58

59. GoF – Estruturais
Decorator <<abstract>>
Component
 Estrutura:
+ op()
ConcreteComponent <<abstract>>
Decorator
+ op()
ConcreteDecoratorA ConcreteDecoratorB
component.op()
- addedState - addedState
+ op() + op()
+ addedBehavior() + addedBehavior() 59

60. GoF – Estruturais
Decorator
 Exemplo:
abstract class Decorator{
...
private Component component ;
public Decorator( Component c ){
component = c ;
}
...
public void operation(){
component.operation() ;
}
} 60

61. GoF – Estruturais
Decorator
 Exemplo:
class GoFTest{
...
Component c = new ConcreteDecoratorA(
new ConcreteDecoratorB(
new ConcreteComponent()));
c.operation();
...
}
61

62. GoF – Estruturais
Decorator
 Outro exemplo:
Sanduich s = new Hamburguer(
new Hamburguer(
new Letuce(
new Cheese(
new SpecialSpice(
new Onion(
new Pickles(
new BreadWithGergelim())))))));
62

63. GoF – Estruturais
Decorator
 Use quando:
 Deseja adicionar responsabilidades para
objetos individuais dinamicamente, de
maneira transparente e sem afetar outros
objetos
 Quando uma hierarquia de subclasses não é
prática devido ao grande número de
possibilidades (explosão de classes)
63

64. GoF – Estruturais
Proxy
 Intenção: Fornecer um representante de
um objeto para controlar o acesso ao
mesmo
64

65. GoF – Estruturais
Proxy
 Estrutura: Subject
Client
+ request()
Proxy.request() uses Proxy RealSubject
RealSubject.request()
+ request() + request()
65

66. GoF – Estruturais
Proxy
 Exemplo:
class RealSubject extends Subject{
...
public request(){
// implementation of the request
}
...
}
66

67. GoF – Estruturais
Proxy
 Exemplo:
class Proxy extends Subject{
...
public request(){
Subject s = new RealSubject() ;
s.request() ;
}
...
}
67

68. GoF – Estruturais
Proxy
 Exemplo:
class GoFTest{
...
Subject s = new Proxy() ;
s.request() ;
...
}
68

69. GoF – Estruturais
Proxy
 Use quando:
 Há a necessidade de uma referência
sofisticada ou versátil a um objeto (mais do
que um simples ponteiro)
69

70. GoF – Estruturais
Adapter
 Intenção: Converter a interface de uma
classe em outra que os clientes esperam
70

71. GoF – Estruturais
Adapter
 Estrutura (class adapter):
<<abstract>> Adaptee
Target
Client
+ request() + specificRequest()
Adapter
specificRequest()
+ request()
71

72. GoF – Estruturais
Adapter
 Estrutura (object adapter):
<<abstract>> Adaptee
Target
Client
+ request() + specificRequest()
Adapter
+ request() adaptee.specificRequest()
72

73. GoF – Estruturais
Adapter
 Exemplo (object adapter):
abstract class Target{
public abstract void request();
}
class Adapter extends Target{
public void request(){
Adaptee a = new Adaptee();
a.specificRequest();
}
}
73

74. GoF – Estruturais
Adapter
 Use quando:
 Deseja usar uma classe existente, mas sua
interface não combina com o que precisa
 Você precisa criar classes reutilizáveis que
cooperem com classes não previstas
74

75. GoF – Estruturais
Facade
 Intenção: Fornecer uma interface
unificada para um conjunto de interfaces
de um subsistema
75

76. GoF – Estruturais
Facade
 Estrutura:
Façade
subsystem classes
76

77. GoF – Estruturais
Facade
 Exemplo:
class Facade{
public Response parseRequest(
Request r ){
RequestController rc;
rc = RequestController.getInstance();
return rc.parse( r );
}
public boolean areYouAlive(){
SystemController sc ;
sc = SystemController.getInstance() ;
return sc.isAlive();
}
}
77

78. GoF – Estruturais
Facade
 Use quando:
 Precisar de uma interface simples para um
subsistema complexo
 Há muitas dependências entre clientes e
classes de implementações de uma abstração
 Desejar dividir seu sistema em camadas
78

79. GoF – Estruturais
Bridge
 Intenção: Desacoplar uma abstração de
sua implementação, de modo que as
duas possam variar independentemente
79

80. GoF – Estruturais
Bridge
 Estrutura:
<<abstract>> <<abstract>>
Abstraction Implementor
Client
+ operation() + operationImpl ()
RefinedAbstraction ImplementorA ImplementorB
+ operation() + operationImpl () + operationImpl ()
80

81. GoF – Estruturais imp.devDrawLine()
imp.devDrawLine()
Bridge imp.devDrawLine()
imp.devDrawLine()
 Exemplo:
<<abstract>> <<abstract>>
Window WindowImpl
Client
+ drawRect() + devDrawLine ()
RefinedAbstraction XWindowImpl PMManager
+ drawRect() + devDrawLine () + devDrawLine ()
81

82. GoF – Estruturais
Bridge
 Use quando:
 Deseja evitar acoplamento permanente entre
abstração e sua implementação
 Abstração e implementação devem ser
extensíveis
 Mudanças na implementação não devem ter
impactos nos clientes que usam a abstração
82

83. GoF – Estruturais
Flyweight
 Intenção: Usar compartilhamento para
suportar eficientemente grandes
quantidades de objetos com
granularidade fina
83

84. if( flyweight[key] exists){
GoF – Estruturais return flyweight[key]
} else {
Flyweight
create new flyweight;
add it to pool of flyweight;
return the new flyweight
}
 Estrutura:
FlyweightFactory Flyweight
+ getFlyweight(key) + operation(extrinsicState)
ConcreteFlyweight UnsharedConcreteFlwweight
Client
- intrinsicState - allState
+ operation(extrinsicState) + operation(extrinsicState)
84

85. GoF – Estruturais
Flyweight
 Exemplo:
class FlyweightFactory{
private Flyweight pool[];
public Flyweight getFlyweight(int key)
{
if( pool[ key ] != null ){
pool[key] =
new ConcreteFlyweight();
}
return pool[key] ;
}
}
85

86. GoF – Estruturais
Flyweight
 Exemplo:
class GoFTest{
...
private fc FlyweightFactory;
fc = new FlyweightFactory();
Flyweight f =
fc.getFlyweight( Flyweight.A );
f.operation( newState ) ;
f.run();
...
}
86

87. GoF – Estruturais
Flyweight
 Use quando todos estes forem verdade:
 Uma aplicação usa um grande número de objetos
 Custo de armazenagem é alto (muitos objetos)
 Boa parte do estado do objeto pode ser extrínseca
 Muitos grupos de objetos podem ser trocados por
relativamente poucos objetos quando a parte
extrínseca é removida
 A aplicação não depende da identidade dos
objetos, uma vez que serão compartilhados
87

88. Exercício
 Continuar projeto do sistema de
fiscalização de velocidade
 Incorporandopadrões estruturais
 Descrevendo métodos e atributos principais
88

89. GoF – Comportamentais
(Capítulo 5)
 Template method  State
 Interpreter  Strategy
 Mediator  Command
 Chain of responsibility  Memento
 Observer  Iterator
 Visitor
89

90. GoF – Comportamentais
Template Method
 Intenção:
 Definiro esqueleto de um algoritmo
postergando alguns passos para as
subclasses
 As subclasses podem redefinir certos passos
de um algoritmo sem mudar sua estrutura
90

91. GoF – Comportamentais
Template Method
 Estrutura: <<abstract>>
AbstractClass public void templateMethod(){
...
op1()
+ templateMethod() ...
+ op1() <<abs>> op2()
+ op2() <<abs>> ...
}
ConcreteClass
+ op1()
+ op2()
91

92. GoF – Comportamentais
Template Method
 Exemplo:
<<abstract>>
Clusterer public void doCluster( Object o ){
...
// for all the objects
+ doCluster( o ) d = getDistance( o ) ;
+ getDistance( o ) // add to the closest cluster’s centroid
+ updateCentroids() ...
// after setting clusters to all objects
Abstract methods updateCentroids() ;
...
// do it untill centroids don’t change
EuclideanClusterer }
+ getDistance()
+ updateCentroid() 92

93. GoF – Comportamentais
Template Method
 Use quando:
 Deseja implementar partes invariantes de um
algoritmo uma vez e deixar que subclasses
implementem o comportamento que pode
variar
 Um comportamento comum de subclasses
pode ser divido e colocado em uma classe
comum para evitar duplicação de código
 Desejar controlar extensão de subclasses
93

94. GoF – Comportamentais
Interpreter
 Intenção: Dada uma linguagem, definir
uma representação para sua gramática
juntamente com um interpretador que usa
a representação para interpretar
sentenças na linguagem
94

95. GoF – Comportamentais
Interpreter
 Estrutura:
<<abstract>>
Expression
Client
+ interpret(Context)
Context
TerminalExpression NonterminalExpression
+ interpret(Context) + interpret(Context)
95

96. GoF – Comportamentais
Interpreter
 Exemplo:
<<abstract>>
SpreadSheetExpression
Client
+ interpret(Context)
Context
NumberExpression CellExpression
+ interpret(Context) + interpret(Context)
96

97. GoF – Comportamentais
Interpreter
 Use quando:
 Há uma gramática para interpretar e você
pode representar sentenças dessa linguagem
como árvores abstratas de sintaxe
 Funciona melhor quando
 A gramática é simples
 Eficiência não é um ponto crítico
97

98. GoF – Comportamentais
Mediator
 Intenção:
 Definir um objeto que encapsula a forma
como um conjunto de objetos interage
 Promove o baixo acoplamento evitando que
objetos façam referência a outros
explicitamente
98

99. GoF – Comportamentais
Mediator
 Estrutura:
<<abstract>> <<abstract>>
Mediator Colleague
ConcreteMediator ConcreteColleagueA ConcreteColleagueB
99

100. GoF – Comportamentais
Mediator mediator.propagate( this )
 Exemplo:
<<abstract>> <<abstract>>
Mediator UIComponent
+ propagate( UIComponent ) + changed()
ConcreteMediator SuggestionsList TextField
+ setList( String ) + setText( String )
+ propagate( UIComponent ) + getSelection() + getText()
100

101. GoF – Comportamentais
Mediator
 Use quando:
 Objetos se comunicam de maneira bem
definida, mas complexa
 Um objeto tem reúso restrito pois se
comunica e referencia muitos objetos
 Um comportamento que é distribuído entre
várias classes deveria ser customizável sem
utilizar muita herança
101

102. GoF – Comportamentais
Chain of Responsibility
 Intenção:
 Evitar acoplamento entre remetente e
destinatário de um pedido, dando a mais de
um objeto a chance de responder um pedido
 Encadeia objetos e passa request até que um
deles responda
102

103. GoF – Comportamentais
Chain of Responsibility
 Estrutura:
Handler
- successor
Client
+ handleRequest()
if can handle request{
handle request
} else {
successor.handleRequest() ConcreteHandler1 ConcreteHandler2
}
+ handleRequest() + handleRequest()
103

104. GoF – Comportamentais
Chain of Responsibility
 Exemplo:
EventLogger
- successor
Client
+ log( Event )
if can log Event{
log Event data
} else {
successor.log( Event ) MouseLogger KeyPressLogger
}
+ log( Event ) + log( Event )
104

105. GoF – Comportamentais
Chain of Responsibility
 Use quando:
 Mais de um objeto pode manipular uma
requisição e o handler não é conhecido de
antemão. O handler deveria ser associado
automaticamente
 Você quer enviar uma requisição para vários
objetos sem especificar o destinatário
explicitamente
 O conjunto de objetos que pode manipular
uma requisição pode ser especificado
dinamicamente 105

106. GoF – Comportamentais
Observer
 Intenção: Define uma interdependência
1 para n entre objetos, de forma que
quando um objeto muda de estado,
todos os seus dependentes são
notificados e atualizados
106

107. GoF – Comportamentais
Observer
 Estrutura: <<abstract>>
Subject <<abstract>>
Observer
+ attach( Observer )
+ detach( Observer ) + update()
+ notify()
ConcreteObserver
ConcreteSubject - observerState
for all o in observres{
o.update() ; + update()
- state
}
+ getState()
observerState = subject.getState()
+ setState( state )
107

108. GoF – Comportamentais
Observer
 Exemplo:
class ConcreteSubject extends Subject{
private List<Observer> observers ; //N
private State state ;
...
public void attach( Observer o ){
o.setSubject( this ) ;
observers.add( o ) ;
}
... (continua)
108

109. GoF – Comportamentais
Observer
 Exemplo:
public void detach( Observer o ){
o.setSubject( null ) ;
observers.remove( o ) ;
}
public void notify(){
// i is iterator of observers list
while(i.hasNext()){
Observer o = i.next() ;
o.update() ;
}
}
}
109

110. GoF – Comportamentais
Observer
 Exemplo:
class ConcreteObserver extends Observer{
private Subject subject ; //1
private State state ;
...
public void setSubject( Subject s ){
subject = s ;
}
public void update(){
state = subject.getState() ;
}
}
110

111. GoF – Comportamentais
Observer
 Exemplo:
class GoFTest{
...
public static void main( String args[] ){
// 1 ‘source’
Subject s = new ConcreteSubject() ;
// N dependents
Observer o1 = new ConcreteObserver() ;
s.attach( o1 ) ;
Observer o2 = new ConcreteObserver() ;
s.attach( o2 ) ;
...
}
}
111

112. GoF – Comportamentais
Observer
 Use quando:
 Uma abstração tiver dois aspectos, um
dependente do outro. Encapsular esses
aspectos em objetos separados possibilita
reusá-los independentemente
 Uma mudança 1:n ocorre e você não sabe
quantos objetos precisam ser alterados
 Um objeto precisa notificar outros objetos sem
fazer suposições sobre quem eles são
112

113. GoF – Comportamentais
Observer
 Considerando o sensor de um radar de
velocidade, o que é mais adequado
Mediator ou Observer?
<<colleague>> <<colleague>> <<observer>>
Display Camera Display
<<subject>>
Mediator Sensor
<<observer>>
<<colleague>>
Camera
Sensor 113

114. GoF – Comportamentais
State
 Intenção: Permite a um objeto alterar seu
comportamento quando seu estado
interno muda. O objeto parecerá ter
“mudado de classe”
114

115. GoF – Comportamentais
State
 Estrutura:
<<abstract>>
Context
State
+ request() + handle ()
state.handle()
ConcreteStateA ConcreteStateB
+ handle () + handle()
115

116. GoF – Comportamentais
State
 Exemplo:
class Sensor{
private State state ;
public setState( State s ){
state = s ;
}
public int trackSpeed(){
return state.handle( this ) ;
}
}
116

117. GoF – Comportamentais
State
 Exemplo:
abstract class State{
abstract void handle( Sensor s ) ;
}
class CarPassing extends State{
public int handle( Sensor s ){
int speed = s.getSpeed() ;
s.setState( new NoCarPassing() );
return speed ;
}
}
117

118. GoF – Comportamentais
State
 Use quando:
O comportamento de um objeto depende do
seu estado ele deve mudá-lo em tempo de
execução
 Operações tem vários fluxos condicionais que
dependem do estado do objeto. State coloca
cada um desses fluxos em uma classe
separada
118

119. GoF – Comportamentais
Strategy
 Intenção:
 Define uma família de algoritmos, encapsula
cada um deles e os torna intercambiáveis
 Strategy permite que o algoritmo varie
independentemente dos clientes que a
utilizam
119

120. GoF – Comportamentais
Strategy
 Estrutura:
<<abstract>>
Context
Strategy
+ contextInterface() + algorithm ()
strategy.algorithm()
ConcreteStrategyA ConcreteStrategyB
+ algorithm () + algorithm ()
120

121. GoF – Comportamentais
Strategy
 Exemplo:
<<abstract>>
Context
Sorter
+ showList() + sort ( List )
sorter.sort( List )
BubbleSorter MergeSorter
+ sort ( List ) + sort ( List )
121

122. GoF – Comportamentais
Strategy
 Use quando:
 Várias classes relacionadas diferem somente
no comportamento
 Precisa de variantes de um certo algoritmo
 Um algoritmo usa dados que clientes não
precisam ter conhecimento
 Uma classe define muitos comportamentos
que aparecem em vários fluxos condicionais
122

123. GoF – Comportamentais
Command
 Intenção:
 Encapsular uma requisição em um objeto,
permitindo
 parametrizar clientes
 enfileirar requisições
 registrar requisições
 suportar operações que podem ser desfeitas
123

124. GoF – Comportamentais
Command
 Estrutura:
<<abstract>>
Invoker
Command
+ execute () <<abstract>>
Receiver ConcreteCommand
Client - state
+ action () + execute ()
124

125. GoF – Comportamentais
Command
 Exemplo:
<<abstract>>
Menu MenuItem
Command
+ clicked() + execute () <<abstract>>
command.execute() document.paste()
Document DeleteCommand
Application + delete () - state
+ copy()
+ execute ()
+ paste()
125

126. GoF – Comportamentais
Command
 Use quando:
 Desejar parametrizar objetos com base na ação a
ser executada
 Desejar especificar filas e executar solicitações em
tempos diferentes
 Desejar implementar “desfazer”
 Desejar implementar logging de ações para serem
reaplicadas em sistemas em caso de crash
 Desejar estruturar um sistema em operações em
alto nível construídas com base em operações
primitivas 126

127. GoF – Comportamentais
Memento
 Intenção: Sem violar encapsulamento,
capturar e externalizar o estado interno
de um objeto de maneira que o objeto
possa retornar a esse estado mais tarde
127

128. GoF – Comportamentais
Memento
 Estrutura:
Originator Caretaker
Memento
- state - state
+ setMemento(Memento m) + getState()
+ createMemento() + setState(State s)
return new Memento(state) state = m.getState()
128

129. GoF – Comportamentais
Memento
 Exemplo:
Game CheckpointController
Checkpoint
- state - state
+setCheckpoint(Checkpoint c) + getState()
+createCheckpoint() + setState(State s)
return new Checkpoint(state) state = c.getState()
129

130. GoF – Comportamentais
Memento
 Use quando:
 Um snapshot de alguma parte do objeto
precisa ser salva para que seja restaurada no
futuro; e
 Uma interface direta para obter o estado
expõe detalhes de implementação e quebraria
o encapsulamento do objeto
130

131. GoF – Comportamentais
Iterator
 Intenção: Fornecer um meio de acessar,
sequencialmente, os elementos de uma
agregação sem expor sua representação
interna
131

132. GoF – Comportamentais
Iterator
 Estrutura: Client <<abstract>>
Iterator
<<abstract>>
Aggregate + first()
+ next()
+ isDone()
+ createIterator() + currentItem()
ConcreteAggregate ConcreteIterator
+ createIterator() return new ConcreteIterator(this)
132

133. GoF – Comportamentais
Iterator
 Exemplo: Client <<abstract>>
Iterator
<<abstract>>
AbstractTree + first()
+ next()
+ isDone()
+ createIterator() + currentItem()
BinaryTree BinaryTreeIterator
+ createIterator()
return new BinaryTreeIterator(this)
133

134. GoF – Comportamentais
Iterator
 Use quando:
 Quiser acessar conteúdo de uma coleção de
objetos sem expor sua representação interna
 Quiser fornecer uma interface uniforme para
navegar em diferentes estruturas de coleções
de objetos (suportar iteração polimórfica)
134

135. GoF – Comportamentais
Visitor
 Intenção:
 Representar uma operação a ser executada
nos elementos de uma estrutura de objetos.
 Visitor permite definir uma nova operação
sem mudar a classe dos elementos sobre os
quais opera
135

136. GoF – Comportamentais
Visitor
 Estrutura: Client
<<abstract>> <<abstract>>
Element Visitor
ObjectStructure
+ accept( Visitor ) + visitElement(ConcreteElement)
ConcreteElement ConcreteVisitor
+ accept ( Visitor v )
+ op() v.visitConcreteElement( this )
136

137. GoF – Comportamentais
Visitor
 Exemplo: Client
<<abstract>> <<abstract>>
Node Visitor
Graph
+ visitNode(ConcreteNode)
+ accept( Visitor )
+ visitNode(OtherConcreteNode)
ConcreteNode NodeVisitor
+ accept ( Visitor v )
+ op() v.visitNode( this )
137

138. GoF – Comportamentais
Visitor
 Use quando:
 A estrutura de um objeto contém muitas classes
de objetos com interfaces diferentes e você
deseja realizar operações nesses objetos
 Operações diferentes e não relacionadas precisam
ser aplicadas em uma estrutura de objetos e você
não deseja “poluí-los” com essas operações
 Classes definindo estruturas raramente mudam,
mas comumente você deseja definir novas
operações nessa estrutura
138

139. GoF
Relacionamento entre padrões
Builder Iterator Memento Adapter Proxy
Decorator Visitor
Bridge
Command
Composite
Flyweight
Chain of Responsibility
Strategy
Interpreter
State
Template Method Mediator Observer
Prototype
Factory Method
Abstract Factory
Facade
Singleton
139

140. Exercício
 Finalizar projeto do sistema de
fiscalização de velocidade para
apresentação na próxima aula
 20min por grupo
 10min de discussões
140

141. Referências
 Chidamber & Kemerer
A Metrics Suite for Object Oriented Design
 Gamma et al.
Design Patterns: Elements of Reusable Object-Oriented
Software (1994)
 Larman
Applying UML and Patterns: An Introduction to Object-
Oriented Analysis and Design and Iterative Development
(3rd Edition)
141