1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra Outubro/2005.

Apresentação em tema: "1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra Outubro/2005."— Transcrição da apresentação:

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

2 2 Agenda Command Chain of Responsibility Prototype Bridge Builder

3 3 Command

4 4 Definição: encapsula uma requisição como um objeto, permitindo a parametrização de clientes com diferentes requisições. RemetenteReceptor RemetenteCommandReceptor Sem Command, o cliente conhece o servidor. Com Command, o cliente não conhece o servidor. req

5 5 Command (estrutura) * Client Invoker action() Receiver execute() Command execute() state ConcreteCommand receiver.action()

6 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.

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

8 8 Command (exemplo de interação) : Client : Receiver : Invoker : ConcreteCommand create() store( aCommand ) action() execute()

9 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.

10 10 Chain of Responsibility

11 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.

12 12 Estrutura do Chain of Responsibility

13 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

14 14 Chain of Responsibility - Exemplo Correspondências no exemplo do DoFactory: –Handler (Approver) –ConcreteHandler (Director, VicePresident, President) –Client (ChainApp)

15 15 Prototype

16 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.

17 17 Estrutura do Prototype

18 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.

19 19 Bridge

20 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.

21 21 Estrutura do Bridge

22 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.

23 23 Builder

24 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”

25 25 Builder - estrutura

26 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.

27 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.

28 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.

29 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.