Padrões de Projeto
Upcoming SlideShare
Loading in...5
×
 

Padrões de Projeto

on

  • 6,835 views

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

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

Statistics

Views

Total Views
6,835
Views on SlideShare
6,824
Embed Views
11

Actions

Likes
4
Downloads
261
Comments
1

2 Embeds 11

http://www.plasticdesign.eti.br 8
http://plasticdesign.eti.br 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Template Method define um algoritmo em termos de operações abstratas que subclasses sobrescrevem para fornecer comportamento concreto.
  • Context tem o contexto usado pelo interpretador e interpret verifica até que ponto a string segue a gramática.
  • A invocação do método vai do mais específico para o mais genérico. Uma analogia possível é a de solução de problemas considerando organogramas.
  • No Mediator objetos precisam interagir, no Observer todos n objetos dependem do estado do objeto 1. Assim, os n objetos são notificados da mudança do objeto 1.

Padrões de Projeto Padrões de Projeto Presentation Transcript

  • 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
  • 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
  • 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
  • IntroduçãoUm 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
  • IntroduçãoUm 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
  • IntroduçãoPor 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
  • IntroduçãoNo 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
  • IntroduçãoComo 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
  • Padrões GRASP Information Expert  Polymorphism Creator  Pure Fabrication Controller  Indirection Low Coupling  Protected Variations High Cohesion 9
  • Padrões GRASPInformation 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
  • Padrões GRASPCreator 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
  • Padrões GRASPController 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
  • Padrões GRASPController – 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
  • Padrões GRASPController – 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
  • Padrões GRASPController – 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
  • Padrões GRASPLow 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
  • Padrões GRASPHigh 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
  • Padrões GRASPExemplo: Space Invaders Fonte: http://www.freespaceinvaders.org/ 18
  • Padrões GRASPExemplo: 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
  • Padrões GRASPPolymorphism 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
  • Padrões GRASPPure 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
  • Padrões GRASPIndirection 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
  • Padrões GRASPProtected 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
  • 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
  • Métricas CKCBO 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
  • Métricas CKLCOM 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
  • Métricas CKLCOM 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
  • Padrões GRASPExemplo: Tetris 28
  • GoF – Criacionais (Capítulo 3) Singleton Factory Method Abstract Factory Prototype Builder 29
  • GoF – CriacionaisSingleton Intenção: Garantir que uma classe tenha somente uma instância e fornecer um ponto de acesso à instancia 30
  • GoF – CriacionaisSingleton Estrutura: <<singleton>> Class A Client - static instance : Class A - Class A() + static getInstance() : Class A 31
  • GoF – CriacionaisSingleton Exemplo: class Singleton{ private static Singleton instance; private Singleton{ } public static Singleton getInstance(){ if( instance == null ) instance = new Singleton(); return instance; } } 32
  • GoF – CriacionaisSingleton 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
  • GoF – CriacionaisFactory Method Intenção: Definir uma interface para criação de um objeto, mas deixar as subclasses decidirem qual classe instanciar 34
  • GoF – CriacionaisFactory Method Estrutura: <<abstract>> <<abstract>> Creator Product + factoryMethod() <<abstract>> ConcreteCreator ConcreteProduct creates + factoryMethod() 35
  • GoF – CriacionaisFactory Method Exemplo: abstract class Product{ ... } class ConcreteProductA extends Product{ ... } class ConcreteProductB extends Product{ ... } 36
  • GoF – CriacionaisFactory 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
  • GoF – CriacionaisFactory 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
  • GoF – CriacionaisFactory 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
  • GoF – CriacionaisAbstract Factory Intenção: Fornecer interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas 40
  • GoF – CriacionaisAbstract Factory Estrutura: <<abstract>> AbstractFactory + createA() <<abstract>> + createB() <<abstract>> ConcreteFactory1 ConcreteFactory2 + createA() + createA() + createB() + createB() 41
  • GoF – CriacionaisAbstract 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
  • GoF – CriacionaisPrototype 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
  • GoF – CriacionaisPrototype Estrutura: Client Prototype + op() + clone() ConcretePrototype prototype -> clone() + clone() return copy of self 44
  • GoF – CriacionaisPrototype Graphic Exemplo: + draw( coord ) + clone() GraphicTool Staff MusicalNote + draw( coord ) + draw( coord ) + clone() + clone() WholeNote HalfNote + draw( coord ) + draw( coord ) + clone() + clone() 45
  • GoF – CriacionaisPrototype 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
  • GoF – CriacionaisBuilder 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
  • GoF – CriacionaisBuilder Estrutura: <<abstract>> Director Builder+ construct() + buildPart() ConcreteBuilderfor( Object o : Collection ) Product builder -> buildPart() + buildPart() + getResult() 48
  • GoF – CriacionaisBuilder Exemplo: class Director{ ... private Builder b ; b = new ConcreteBuilder() ; for( Object o : Collection ) b.buildPart( o ) ; Product p = b.getResult() ; ... } 49
  • GoF – CriacionaisBuilder 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
  • GoF – CriacionaisBuilder 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
  • 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
  • GoF – Estruturais (Capítulo 4) Composite Decorator Proxy Adapter Bridge Facade Flyweight 53
  • GoF – EstruturaisComposite Intenção: Compor objetos em estruturas de árvore para representarem hierarquias do tipo todo-parte 54
  • GoF – EstruturaisComposite Estrutura: <<abstract>> Component + op() Client + add( :Component ) + remove( :Component ) + getChild( int ) Leaf Composite + op() + op() + add( :Component ) + remove( :Component ) + getChild( int ) 55
  • GoF – EstruturaisComposite Exemplo: <<abstract>> Component * + op() Client + add( :Component ) + remove( :Component ) + getChild( int ) File Directory + op() + op() + add( :Component ) + remove( :Component ) + getChild( int ) 56
  • GoF – EstruturaisComposite 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
  • GoF – EstruturaisDecorator Intenção: Dinamicamente, agregar funcionalidades a um objeto 58
  • GoF – EstruturaisDecorator <<abstract>> Component Estrutura: + op() ConcreteComponent <<abstract>> Decorator + op() ConcreteDecoratorA ConcreteDecoratorB component.op() - addedState - addedState + op() + op() + addedBehavior() + addedBehavior() 59
  • GoF – EstruturaisDecorator Exemplo: abstract class Decorator{ ... private Component component ; public Decorator( Component c ){ component = c ; } ... public void operation(){ component.operation() ; } } 60
  • GoF – EstruturaisDecorator Exemplo: class GoFTest{ ... Component c = new ConcreteDecoratorA( new ConcreteDecoratorB( new ConcreteComponent())); c.operation(); ... } 61
  • GoF – EstruturaisDecorator Outro exemplo: Sanduich s = new Hamburguer( new Hamburguer( new Letuce( new Cheese( new SpecialSpice( new Onion( new Pickles( new BreadWithGergelim()))))))); 62
  • GoF – EstruturaisDecorator 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
  • GoF – EstruturaisProxy Intenção: Fornecer um representante de um objeto para controlar o acesso ao mesmo 64
  • GoF – EstruturaisProxy Estrutura: Subject Client + request() Proxy.request() uses Proxy RealSubject RealSubject.request() + request() + request() 65
  • GoF – EstruturaisProxy Exemplo: class RealSubject extends Subject{ ... public request(){ // implementation of the request } ... } 66
  • GoF – EstruturaisProxy Exemplo: class Proxy extends Subject{ ... public request(){ Subject s = new RealSubject() ; s.request() ; } ... } 67
  • GoF – EstruturaisProxy Exemplo: class GoFTest{ ... Subject s = new Proxy() ; s.request() ; ... } 68
  • GoF – EstruturaisProxy Use quando:  Há a necessidade de uma referência sofisticada ou versátil a um objeto (mais do que um simples ponteiro) 69
  • GoF – EstruturaisAdapter Intenção: Converter a interface de uma classe em outra que os clientes esperam 70
  • GoF – EstruturaisAdapter Estrutura (class adapter): <<abstract>> Adaptee Target Client + request() + specificRequest() Adapter specificRequest() + request() 71
  • GoF – EstruturaisAdapter Estrutura (object adapter): <<abstract>> Adaptee Target Client + request() + specificRequest() Adapter + request() adaptee.specificRequest() 72
  • GoF – EstruturaisAdapter Exemplo (object adapter): abstract class Target{ public abstract void request(); } class Adapter extends Target{ public void request(){ Adaptee a = new Adaptee(); a.specificRequest(); } } 73
  • GoF – EstruturaisAdapter 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
  • GoF – EstruturaisFacade Intenção: Fornecer uma interface unificada para um conjunto de interfaces de um subsistema 75
  • GoF – EstruturaisFacade Estrutura: Façadesubsystem classes 76
  • GoF – EstruturaisFacade 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
  • GoF – EstruturaisFacade 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
  • GoF – EstruturaisBridge Intenção: Desacoplar uma abstração de sua implementação, de modo que as duas possam variar independentemente 79
  • GoF – EstruturaisBridge Estrutura: <<abstract>> <<abstract>> Abstraction Implementor Client + operation() + operationImpl () RefinedAbstraction ImplementorA ImplementorB + operation() + operationImpl () + operationImpl () 80
  • 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
  • GoF – EstruturaisBridge 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
  • GoF – EstruturaisFlyweight Intenção: Usar compartilhamento para suportar eficientemente grandes quantidades de objetos com granularidade fina 83
  • 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
  • GoF – EstruturaisFlyweight Exemplo: class FlyweightFactory{ private Flyweight pool[]; public Flyweight getFlyweight(int key) { if( pool[ key ] != null ){ pool[key] = new ConcreteFlyweight(); } return pool[key] ; } } 85
  • GoF – EstruturaisFlyweight Exemplo: class GoFTest{ ... private fc FlyweightFactory; fc = new FlyweightFactory(); Flyweight f = fc.getFlyweight( Flyweight.A ); f.operation( newState ) ; f.run(); ... } 86
  • GoF – EstruturaisFlyweight 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
  • Exercício Continuar projeto do sistema de fiscalização de velocidade  Incorporandopadrões estruturais  Descrevendo métodos e atributos principais 88
  • GoF – Comportamentais(Capítulo 5) Template method  State Interpreter  Strategy Mediator  Command Chain of responsibility  Memento Observer  Iterator  Visitor 89
  • GoF – ComportamentaisTemplate 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
  • GoF – ComportamentaisTemplate Method Estrutura: <<abstract>> AbstractClass public void templateMethod(){ ... op1() + templateMethod() ... + op1() <<abs>> op2() + op2() <<abs>> ... } ConcreteClass + op1() + op2() 91
  • 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 objectsAbstract methods updateCentroids() ; ... // do it untill centroids don’t change EuclideanClusterer } + getDistance() + updateCentroid() 92
  • GoF – ComportamentaisTemplate 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
  • GoF – ComportamentaisInterpreter 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
  • GoF – ComportamentaisInterpreter Estrutura: <<abstract>> Expression Client + interpret(Context) Context TerminalExpression NonterminalExpression + interpret(Context) + interpret(Context) 95
  • GoF – ComportamentaisInterpreter Exemplo: <<abstract>> SpreadSheetExpression Client + interpret(Context) Context NumberExpression CellExpression + interpret(Context) + interpret(Context) 96
  • GoF – ComportamentaisInterpreter 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
  • GoF – ComportamentaisMediator 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
  • GoF – ComportamentaisMediator Estrutura: <<abstract>> <<abstract>> Mediator Colleague ConcreteMediator ConcreteColleagueA ConcreteColleagueB 99
  • GoF – ComportamentaisMediator mediator.propagate( this ) Exemplo: <<abstract>> <<abstract>> Mediator UIComponent + propagate( UIComponent ) + changed() ConcreteMediator SuggestionsList TextField + setList( String ) + setText( String ) + propagate( UIComponent ) + getSelection() + getText() 100
  • GoF – ComportamentaisMediator 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
  • GoF – ComportamentaisChain 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
  • GoF – Comportamentais Chain of Responsibility  Estrutura: Handler - successor Client + handleRequest()if can handle request{ handle request} else { successor.handleRequest() ConcreteHandler1 ConcreteHandler2} + handleRequest() + handleRequest() 103
  • 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
  • GoF – ComportamentaisChain 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
  • GoF – ComportamentaisObserver 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
  • GoF – ComportamentaisObserver Estrutura: <<abstract>> Subject <<abstract>> Observer + attach( Observer ) + detach( Observer ) + update() + notify() ConcreteObserver ConcreteSubject - observerStatefor all o in observres{ o.update() ; + update() - state} + getState() observerState = subject.getState() + setState( state ) 107
  • GoF – ComportamentaisObserver 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
  • GoF – ComportamentaisObserver 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
  • GoF – ComportamentaisObserver 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
  • GoF – ComportamentaisObserver 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
  • GoF – ComportamentaisObserver 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
  • GoF – ComportamentaisObserver 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
  • GoF – ComportamentaisState Intenção: Permite a um objeto alterar seu comportamento quando seu estado interno muda. O objeto parecerá ter “mudado de classe” 114
  • GoF – ComportamentaisState Estrutura: <<abstract>> Context State + request() + handle () state.handle() ConcreteStateA ConcreteStateB + handle () + handle() 115
  • GoF – ComportamentaisState Exemplo: class Sensor{ private State state ; public setState( State s ){ state = s ; } public int trackSpeed(){ return state.handle( this ) ; } } 116
  • GoF – ComportamentaisState 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
  • GoF – ComportamentaisState 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
  • GoF – ComportamentaisStrategy 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
  • GoF – ComportamentaisStrategy Estrutura: <<abstract>> Context Strategy + contextInterface() + algorithm () strategy.algorithm() ConcreteStrategyA ConcreteStrategyB + algorithm () + algorithm () 120
  • GoF – ComportamentaisStrategy Exemplo: <<abstract>> Context Sorter + showList() + sort ( List ) sorter.sort( List ) BubbleSorter MergeSorter + sort ( List ) + sort ( List ) 121
  • GoF – ComportamentaisStrategy 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
  • GoF – ComportamentaisCommand 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
  • GoF – ComportamentaisCommand Estrutura: <<abstract>> Invoker Command + execute () <<abstract>> Receiver ConcreteCommand Client - state + action () + execute () 124
  • GoF – ComportamentaisCommand Exemplo: <<abstract>> Menu MenuItem Command + clicked() + execute () <<abstract>> command.execute() document.paste() Document DeleteCommand Application + delete () - state + copy() + execute () + paste() 125
  • GoF – ComportamentaisCommand 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
  • GoF – ComportamentaisMemento 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
  • GoF – ComportamentaisMemento Estrutura: Originator Caretaker Memento- state - state+ setMemento(Memento m) + getState()+ createMemento() + setState(State s) return new Memento(state) state = m.getState() 128
  • 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
  • GoF – ComportamentaisMemento 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
  • GoF – ComportamentaisIterator Intenção: Fornecer um meio de acessar, sequencialmente, os elementos de uma agregação sem expor sua representação interna 131
  • GoF – Comportamentais Iterator  Estrutura: Client <<abstract>> Iterator <<abstract>> Aggregate + first() + next() + isDone()+ createIterator() + currentItem() ConcreteAggregate ConcreteIterator + createIterator() return new ConcreteIterator(this) 132
  • GoF – Comportamentais Iterator  Exemplo: Client <<abstract>> Iterator <<abstract>> AbstractTree + first() + next() + isDone()+ createIterator() + currentItem() BinaryTree BinaryTreeIterator + createIterator() return new BinaryTreeIterator(this) 133
  • GoF – ComportamentaisIterator 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
  • GoF – ComportamentaisVisitor 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
  • GoF – Comportamentais Visitor  Estrutura: Client <<abstract>> <<abstract>> Element Visitor ObjectStructure+ accept( Visitor ) + visitElement(ConcreteElement) ConcreteElement ConcreteVisitor + accept ( Visitor v ) + op() v.visitConcreteElement( this ) 136
  • 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
  • GoF – ComportamentaisVisitor 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
  • GoF Relacionamento entre padrões Builder Iterator Memento Adapter Proxy Decorator Visitor Bridge Command Composite Flyweight Chain of ResponsibilityStrategy Interpreter State Template Method Mediator ObserverPrototype Factory Method Abstract Factory Facade Singleton 139
  • 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
  • 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