Patron Bridge



BRIDGE

1. CLASIFICACIÓN DEL PATRÓN

Patrón Estructural.

2. INTENCIÓN

Desacopla una abstracción de su implementación con esto las dos pueden variar independientemente.

3. CONOCIDO TAMBIÉN

Handle/body.

4. MOTIVACIÓN

Cuando una abstracción puede tener una de varias practicas posibles, la manera más común de acomodarlas es utilizar herencia. Una clase abstracta define la interfaz en la abstracción, y las subclases concretas la ejecutan de maneras diferentes. Pero este acercamiento no siempre es flexible. La herencia ata una puesta en práctica a la abstracción permanentemente, que hace difícil modificar, ampliar, y reutilizar abstracciones y puestas en práctica independientemente.

Considere la puesta en práctica de una abstracción portable de la ventana en un Toolkit de la interfaz de usuario. Esta abstracción debe permitirnos escribir los usos que trabajan en el sistema de la ventana de X e IBM' encargado de la presentación de s (P.M.), por ejemplo. Usando herencia, podríamos definir una ventana y las subclases XWindow y PMWindow de la clase abstracta que ejecutan el interfaz de la ventana para las diversas plataformas. Pero este acercamiento tiene dos desventajas:

· Es incómodo ampliar la abstracción de la ventana para cubrir diversas clases de ventanas o de nuevas plataformas. Imagínese una subclase de IconWindow de la ventana que especializa la abstracción de la ventana para los iconos. Para apoyar IconWindows para ambas plataformas, tenemos que ejecutar dos nuevas clases, XIconWindow y PMIconWindow. Peor, tenemos que definir dos clases para cada clase de ventana. El apoyo de una tercera plataforma requiere otra más subclase de la nueva ventana para cada clase de ventana.

· Hace código de cliente plataforma-dependiente. Siempre que un cliente cree una ventana, ejemplifica una clase concreta que tenga una puesta en práctica específica. Por ejemplo, crear un objeto de XWindow ata la abstracción de la ventana a la puesta en práctica de la ventana de X, que hace al dependiente del código de cliente en la puesta en práctica de la ventana de X. Esto, alternadamente, hace más duro virar el código de cliente hacia el lado de babor a otras plataformas.

5. POSIBLES APLICACIONES PARA EL BRIDGE

Se debe usar el patrón Bridge cuando:

· usted quiere evitar un atascamiento permanente entre una abstracción y su implementación. Éste pudo ser el caso, por ejemplo, cuando la puesta en práctica se debe seleccionar o cambiar en run-time.

· Ambas abstracciones y sus puestas en práctica deben ser extensibles. En este caso, el patrón Bridge deja combinar las diversas abstracciones y puestas en práctica y ampliarlas independientemente.

· Los cambios en la implementación de una abstracción no deben tener ningún impacto en los clientes; es decir, su código no debe ser recompilado.

· (C++) se quiere ocultar la implementación de una abstracción totalmente del cliente. En C++ la representación de una clase es visible en la interfaz de la clase.

· Se quiere compartir una implementación entre objetos múltiples (quizás usando la referencia que cuenta), y este hecho se debe ocultar del cliente.

6. ESTRUCTURA

La estructura básica que maneja el Brigde está compuesta por:

Fig. 1. Diagrama de clases del modelo de uso del Bridge.

7. PARTICIPANTES

· Abstracción: define la abstracción de la interface, mantiene referencia a un objeto de tipo implementor.

· RefinedAbstraction: extiende la interface definida por Abstracción.

· Implementor: define la interface para la implementación de clases. Esta interface no tiene que corresponder exactamente a la implementación de la interface; en el hecho las dos interfaces puede ser absolutamente diferente. La interfaz del ejecutor proporciona típicamente solamente operaciones primitivas, y la abstracción define las operaciones de alto nivel basadas en estos primitivos.

· Concrete Implementor: implementa la interfaz de implementor y define su implementación concreta.

8. COLABORACIONES

La abstracción transmite a peticiones del cliente su objeto del ejecutor.

9. CONSECUENCIAS

El patrón Bridge tiene las siguientes consecuencias:

· Desacoplando la interfaz de la implementación. La implementación no está limitada permanentemente a una interfaz. La implementación de una abstracción se puede configurar en run-time.

· Extensibilidad mejorada. Usted puede ampliar las jerarquías de la abstracción y del ejecutor independientemente.

· Ocultar detalles de la implementación al cliente. Usted puede blindar a clientes de los detalles de puesta en práctica, como la distribución de los objetos del ejecutor y del mecanismo de acompañamiento de la cuenta de la referencia (si los hay).

10. IMPLEMENTACIÓN

Para la implementación del Bridge es recomendable usar algunas “técnicas” para facilitar su uso.

· Solamente un ejecutor. En las situaciones donde hay solamente una implementación, crear una clase abstracta implementor no es necesario. Éste es un caso degenerado del patrón Bridge; hay una relación uno a uno entre la abstracción y el ejecutor. Sin embargo, esta separación es todavía útil cuando un cambio en la implementación de una clase no debe afectar a su existencia cliente-que es, no deben ser recompilados, apenas reconectados.

· Crear el objeto correcto del ejecutor. Cómo, cuándo, y donde usted decide qué clase del ejecutor para ejemplificar cuando hay más de uno. Si la abstracción sabe sobre todas las clases de ConcreteImplementor, después puede ejemplificar una de ellas en su constructor; puede decidir entre ellas basó en los parámetros pasajeros a su constructor. Si, por ejemplo, una clase de la colección apoya puestas en práctica múltiples, la decisión se puede basar en el tamaño de la colección. Una aplicación de lista encadenada se puede utilizar para las pequeñas colecciones y una tabla de elección arbitraria para los más grandes.

· Distribución de ejecutores. Coplien ilustra cómo el idioma de la manija/del cuerpo en C++ se puede utilizar para compartir puestas en práctica entre varios objetos. El cuerpo almacena una cuenta de la referencia que la clase de la manija incremente y decrezca.

11. CÓDIGO DE EJEMPLO

class Window {

public:

Window(View* contents);

// requests handled by window

virtual void DrawContents();

virtual void Open();

virtual void Close();

virtual void Iconify();

virtual void Deiconify();

// requests forwarded to implementation

virtual void SetOrigin(const Point& at);

virtual void SetExtent(const Point& extent);

virtual void Raise();

virtual void Lower();

virtual void DrawLine(const Point&, const Point&);

virtual void DrawRect(const Point&, const Point&);

virtual void DrawPolygon(const Point[], int n);

virtual void DrawText(const char*, const Point&);

protected:

WindowImp* GetWindowImp();

View* GetView();

private:

WindowImp* _imp;

View* _contents; // the window's contents

};

class WindowImp {

public:

virtual void ImpTop() = 0;

virtual void ImpBottom() = 0;

virtual void ImpSetExtent(const Point&) = 0;

virtual void ImpSetOrigin(const Point&) = 0;

virtual void DeviceRect(Coord, Coord, Coord, Coord) = 0;

virtual void DeviceText(const char*, Coord, Coord) = 0;

virtual void DeviceBitmap(const char*, Coord, Coord) = 0;

// lots more functions for drawing on windows...

protected:

WindowImp();

};

12. USOS CONOCIDOS

Se utiliza el patrón Bridge para:

• Para relevar los reveladores de esta responsabilidad, AppKit proporciona Puente de NXImage/NXImageRep. NXImage define el interfaz para manejar imágenes. La puesta en práctica de imágenes se define en una jerarquía separada de la clase de NXImageRep que tiene subclases tales como NXEPSImageRep, NXCachedImageRep, y NXBitMapImageRep. NXImage mantiene una referencia a uno o más objetos de NXImageRep. Si hay más de una puesta en práctica de la imagen, después NXImage selecciona el más apropiado para el dispositivo de exhibición actual. NXImage es incluso capaz de convertir uno puesta en práctica a otra en caso de necesidad. El aspecto interesante de esta variante del puente es que NXImage puede almacenar más de una puesta en práctica de NXImageRep a la vez.

13. PATRONES ASOCIADOS

Un Abstract Factory puede crear y configurar un Bridge particular.

Los patrones de adaptader se engranan hacia la fabricación las clases sin relación del trabajo junto. Se aplica generalmente a los sistemas después de que son diseñados. Bridge, por una parte, se utiliza up-front en un diseño para dejar abstracciones y puestas en práctica variar independientemente.

REFERENCIAS BIBLIOGRÁFICAS

Design Patterns. Elements of Reusable Object-Oriented Software - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides - Addison Wesley (GoF- Gang of Four)

Thinking in patterns in java – Bruce Eckel

Patterns in Java - Mark Grand – Wiley

---