Padrão Bridge (Handle/Body) Design Patterns Padrão Bridge (Handle/Body) Paulo Roberto França

Motivação Visualizador de imagens. (Diferentes formatos) Cada sistema operacional exibe a imagem de uma forma diferente. È inconveniente a extensão da abstração imagem para diferentes formatos em diferentes plataformas.

Motivação Resultado: Proliferação de classes

Motivação Formato de uma imagem (estrutura e representação) A forma como a imagem é exibida varia entre Sistemas operacionais, porém a sua estrutura é a mesma. Windows pode mostrar uma imagem (bitmap) sem conhecimento de seu formato original (BMP, JPG etc...) A representação e a estrutura de um formato de imagem são aspectos diferentes. Devem variar de forma independente de acordo com fatores como: Sistema operacional, hardware etc.. © LES/PUC-Rio

Motivação A Solução O padrão Bridge permite diferentes hierarquias de classes para as abstrações e suas implementações. Podem Variar de forma independente São criadas duas hierarquias de classes relacionadas: a hierarquia de estrutura do formato de imagens e a de representação nas plataformas suportadas. O relacionamento entre as interfaces é a ponte que desacopla a interface da implementação © LES/PUC-Rio

Motivação

Bridge Classificação Propósito Estrutural de Objeto Permitir o desacoplamento de uma abstração de sua implementação Assim ambos podem variar de forma independente Definir classes abstratas para a interface de uma abstração. Definir subclasses concretas para a implementação. Abordagem não é suficientemente flexível. Herança = ligação permanente. Difícil manter a independência © LES/PUC-Rio

Aplicabilidade Evitar vínculo permanente entre abstração e implementação Selecionar ou trocar a implementação dinamicamente Abstração e implementação devem ser extensíveis Cliente não deve ser recompilado no caso de mudanças na implementação. Ocultar a implementação (C++, header apenas da abstração) Evitar proliferação de classes Ocultar do cliente o compartilhamento da implementação entre vários objetos. EX: objetos compartilham a mesma representação de uma string. Padrão bridge coloca a abstração e a implementação em hierarquia de classes separadas. © LES/PUC-Rio

Estrutura e participantes © LES/PUC-Rio

Colaborações Existe uma “ponte” entre a abstração e a implementação. Abstraction repassa as solicitações dos clientes para o seu objeto Implementor © LES/PUC-Rio

Consequências Configurar a implementação em tempo de execução Mudanças na implementação não torna implicam recompilação da classe Abstraction e seus clientes. Melhorias na estrutura do sistema, encorajando o uso o de camadas; a parte de alto nível somente tem que ter conhecimento de Abstraction e Implementor Extensibilidade: pode-se estender as hierarquias de Abstraction e Implementor independentemente Detalhes de implementação são ocultados do cliente © LES/PUC-Rio

Implementação Diagrama de Classe Client: sera nossa tela o interfase grafica para o usuario © LES/PUC-Rio

Implementação Diagrama de Sequência Abstration: define uma interfase abstrata. mantém uma referencia ao objeto tipo implementor © LES/PUC-Rio

Implementação

Implementação RedefineAbstraction estende a interface definida pela abstração © LES/PUC-Rio

Implementação Implementor: define a interface para a implementação de classes, a qual não * tem que corresponder exatamente com a interfase de Abstraction; Alem disso, * as dois interfases podem ser bastante diferentes. geramente a interfase implementor * prover solo operações primitivas, e Abstraction define operações de alto nível * baseadas em estas primitivas. © LES/PUC-Rio

Implementação ConcreteImplementor: Implementa a interface de Implementor e define * sua implementação concreta. * na grafica ou seja na presentação temos dois ConcreteImplementorA e ConcreteImplementorB, mais * pode ser uma sozinha. © LES/PUC-Rio

Implementação

Pradrões Relacionados Abstract Factory Criar e configurar uma bridge Adapter Usado em sistema já projetados Bridge é usado no projeto desde o inicio

F I M