1 Padrões: Bridge (p. 151) Objetivo: separar uma abstração de sua implementação Sinônimos: Handle/Body.

Apresentação em tema: "1 Padrões: Bridge (p. 151) Objetivo: separar uma abstração de sua implementação Sinônimos: Handle/Body."— Transcrição da apresentação:

1 1 Padrões: Bridge (p. 151) Objetivo: separar uma abstração de sua implementação Sinônimos: Handle/Body

2 2 Motivação maneira usual de implementar abstração com várias implementações é herança –classe abstrata define inferface –subclasses concretas definem implementacoes especificas herança nem sempre é flexível –implemtação ligada à abstração pemanentemente

3 3 Motivação (2) Exemplo: Janelas em sistema para construção de interfaces de usuário Com herança: Superclasse “Janela”, subclasses “JanelaX” e “JanelaPM” Problemas com herança: –extensão da abstração para tipos de janelas diferentes e tipos de plataforma diferentes, e.g. Ícones (figura p.151) –código do cliente fica ligado a uma determinada plataforma. cliente deve poder criar janela sem se ligar a plataforma específica

4 4 O padrão: abstração e implementação são colocadas em hierarquias independentes: –uma hierarquia para Interfaces de Janela (Janela, Icone,...) –uma hierarquia para implementações em plataformas específicas (e.g. XWindowImp) todas as operações nas subclasses de Janela são feitas em função de operações abstratas de “WindowImp”. Chamamos a relação entre “Window” e “WindowImp” de ponte (bridge).

5 5 Figura

6 6 Aplicabilidade (1): evitar ligação permanente entre um abstração e sua implementação (e.g. quando implementação pode mudar em tempo de execução) quando tanto abstrações quanto implementações devem ser extensíveis por subclasseamento quando modificações na implementação de uma abstração devem ser transparentes ao cliente (i.e. nao devemos recompilar seu código)

7 7 Aplicabilidade(2): (C++) para esconder completamente implementação da abstração do cliente. quando uma mesma implementação pode ser compartilhada por vários clientes e isto deve ser transparente a eles. quando temos proliferação de classes como a do diagrama. Esta proliferação indica geralmente necessidade de se separar os objetos em partes diferentes.

8 8 Estrutura (fig)

9 9 Participantes Abstração (Janela): define interface, mantem referencia à implementação Abstração Refinada : estensão da interface Implementador (WindowImp): define interface das classes de implentação. Típicamente define operações primitivas utilizadas pela interface da abstração ImplementaçãoConcreta (XWindowImp, PMWindowImp)

10 10 Consequências Interface e implemtação são separadas: –configurabilidade da implementação em tempo de execução –elimina dependências em tempo de compilação (essencial para “binary compatibility” entre diferentes versões de uma biblioteca de classes) –sistemas melhor estruturados: a parte de alto nível de um sistema apenas precisa conhecer “Abstraction” e “Implementor”. Maior estensibilidade Encapsular detalhes de implementação dos clientes

11 11 Implementação Apenas 1 “Implementor”: –caso extremo. Útil apenas quando mudanças na implementação nao devem envolver os clientes Criar o “Implementor” certo: –parâmetros para o construtor de “Abstraction” –utilizar implementação “default” e mudá-la conforme uso. –utilizar “AbstractFactory” Compartilhando implementações: (ver livro) Utilizando herança múltipla (arg!) –para combinar Abstração com Implementação –ligação permanente de uma abstrajção com sua implementação