1 padrões de software padrões gof (parte 2) eduardo bezerra [email protected] outubro/2005

29
1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra [email protected] Outubro/2005

Upload: internet

Post on 22-Apr-2015

105 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

1

Padrões de Software Padrões GoF (Parte 2)

Eduardo Bezerra

[email protected]

Outubro/2005

Page 2: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

2

Agenda

• Command• Chain of Responsibility• Prototype• Bridge• Builder

Page 3: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

3

Command

Page 4: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

4

Command

• Definição: encapsula uma requisição como um objeto, permitindo a parametrização de clientes com diferentes requisições.

Remetente Receptor

Remetente Command Receptor

Sem Command, o cliente conhece o servidor.

Com Command, o cliente não conhece o servidor.

req

req req

Page 5: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

5

Command (estrutura)

*Client Invoker

action()

Receiver

execute()

Command

execute()state

ConcreteCommand

receiver.action()

Page 6: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

6

Command - Componentes

• Command– Declara uma interface para execução de um operação qualquer.

• ConcreteCommand– Define a ligação entre um objeto Receiver e uma ação

– Implementa a operação Execute através da chamada à operação correspondente no Receiver

• Client– Cria um objeto ConcreteCommand e define o seu receptor

• Invoker– Solicita ao command para realizar a requisição

• Receiver– Sabe como realizer as operações associadas

– knows how to perform the operations associated with carrying out the request.

Page 7: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

7

Command - Exemplo

• Correspondências no exemplo do DoFactory:– Command  (Command) – ConcreteCommand  (CalculatorCommand) – Client  (CommandApp) – Invoker  (User) – Receiver  (Calculator)

Page 8: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

8

Command (exemplo de interação)

: Client : Receiver: Invoker

: ConcreteCommandcreate()

store( aCommand )

action()

execute()

Page 9: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

9

Command (conseqüências)

• Isola requisitante do executor;

• Permite registro (log) e/ou retrocesso (undo) de ações;

• Permite execução em instante posterior à requisição– i.e., permite enfileirar ações para processamento em outro momento.

Page 10: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

10

Chain of Responsibility

Page 11: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

11

Chain of Responsibility

• Definição: padrão cuja função principal é evitar o acoplamento de um objeto remetente com o seu objeto receptor.

• Solução: 1. Dar a mais de um objeto a chance de manipular a

mensagem (requisição).

2. Encadear os objetos receptores e passar a mensagem ao longo da cadeia, até que um dos objetos da cadeia seja capaz de responder à mensagem.

Page 12: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

12

Estrutura do Chain of Responsibility

Page 13: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

13

Chain of Responsibility - Participantes

• Handler– define uma interface para manipulação de requisições

– (opcional) implementa a ligação entre os receptores

• ConcreteHandler– Manipula requisições pelas quais é responsável

– Pode fazer accesso ao seu sucessor

– Se ConcreteHandler pode manipular a requisição, ele o faz; senão, ele repassa a requisição para seu sucessor

• Client– Inicia a requisição a um objeto ConcreteHandler da cadeia

Page 14: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

14

Chain of Responsibility - Exemplo

• Correspondências no exemplo do DoFactory:– Handler   (Approver) – ConcreteHandler   (Director, VicePresident, President) – Client   (ChainApp)

Page 15: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

15

Prototype

Page 16: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

16

Prototype

• É utilizado para criar diversas cópias de um mesmo objeto.

• Útil quando a criação de um objeto a partir do zero é muito cara computacionalmente falando.

• Em vez de criar novas instâncias, crie cópias de instâncias pré-existentes (protótipos) e modifique essas cópias, conforme a necessidade.

• O protótipo criado é um clone do objeto original.

Page 17: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

17

Estrutura do Prototype

Page 18: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

18

Prototype - participantes

• Prototype– Declara uma interace para clonar a si próprio

• ConcretePrototype– implementa uma operação para clonar a si próprio. Essa

operação retorna um objeto da mesma classe e com os mesmos valores de atributos to objeto protótipo utilizado.

• Client– Cria um novo objeto através do envio de uma a requisição

a um protótipo para clonar a si próprio.

Page 19: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

19

Bridge

Page 20: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

20

Bridge

• O padrão Bridge permite desacoplar uma abstração de sua implementação, de tal forma que as duas possa variar independentemente uma da outra.– Entenda abstração como uma interface.

– Note que em linguagens como Java, uma classe que implemente uma interface fica acoplada a essa interface (A implements B). O padrão Bridge permite eliminar essa restrição.

Page 21: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

21

Estrutura do Bridge

Page 22: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

22

Bridge (Participantes)

• Abstraction– Define a interface da abstração.

– Mantém uma referência para um objetos to tipo Implementor.

• RefinedAbstraction– estende a interface definida por Abstraction.

• Implementor– Define a interface para classes que implementam a abstração.

– Esta interface não precisa corresponder à interface de Abstraction; in fact the two interfaces can be quite different.

– Tipicamente, a interface Implementation fornece somente operações básicas, e Abstraction define operações de alto nível baseadas nessas primitivas.

• ConcreteImplementor– Implementa a interface Implementor e define sua implementação concreta.

Page 23: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

23

Builder

Page 24: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

24

Builder

• O padrão Builder separa a construção de um objeto complexo da sua representação de tal forma que o mesmo processo de construção possa criar diferentes representações.

• Esse padrão é motivado pelo desejo de variar a representação interna do produto que ele constrói e, ao mesmo tempo, esconder detalhes acerca de como o produto é montado.

• O cliente instrui o objeto builder sobre como criar o objeto a então solicita o resultado da criação.

• GOF: “is intended to decouple the process of building a complex object from the parts that make up the object”

Page 25: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

25

Builder - estrutura

Page 26: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

26

Builder - participantes

• O padrão Builder tem dois participantes principais, Director e Builder.

• O objeto Director, responsável pela organização geral do objeto Product, faz chamadas ao Builder.

• O Builder constrói o objeto complexo, chamado de Product, sob o controle do objeto Director.

Page 27: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

27

Builder - aplicabilidade

• O padrão Builder pode ser aplicado em situações em que alguma coisa (o produto) é formada (criada, construída) a partir de partes menores.

• O padrão criacional Builder permite que se varie a estrutura interna de um produto, assim como a maneira como esse produto é montado.

• The Builder creational pattern lets you vary a product's internal structure, as well as how it gets assembled. Because you construct the object through an abstract interface, you can define a new kind of builder for a product to assemble it from different structures. The client need not know anything about the construction process, nor the parts that make up a product. You get a high degree of control in the construction process.

Page 28: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

28

Builder (exemplo livro GoF)

• Leitor para documentos RTF que exporta para vários formatos.– Programa que converte RTF em outros formatos.

– Consiste de um Leitor/Parser e de um Conversor

– Dá suporte a diferentes conversões e formatos.

• Objetivos:– Deve ser possível adicionar um novo formato facilmente.

– Separar o conversor do Leitor/Parser

– Deve ser possível reutilizar o algoritmo do Leitor/Parser

– O verdadeiro problema é que a quantidade de conversões em pontencial é ilimitado.

– É desejável a possibilidade de adicionar uma nova conversão sem modificar o leitor.

Page 29: 1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra edubezerra@gmail.com Outubro/2005

29

Builder (exemplo livro GoF)

• Cada classe conversora é chamada um BUILDER e a classe leitora é o DIRECTOR.– O padrão Builder separa o algoritmo para tratar um determinado

formato de como um arquivo convertido é criado e representado.