Patrón de Diseño: Bridge

ABSTRACT— The bridge pattern is a design pattern used in software engineering which is meant to "decouple an abstraction from its implementation so that the two can vary independently" [1]. The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.
When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction.

INTRODUCCION

Los patrones estructurales están relacionados con cómo las clases y los objetos se combinan para dar lugar a estructuras más complejas. Puede hacerse la distinción de patrones estructurales asociados a clases y asociados a objetos, los primeros utilizarán la herencia, los segundos la composición.
Los patrones estructurales asociados con objetos describen formas de componer los objetos para conseguir nueva funcionalidad. La flexibilidad de la composición de objetos viene de la posibilidad de cambiar la composición en tiempo de ejecución, lo que es imposible con la composición estática de clases. En el presente documento se da a conocer uno de los patrones de diseño asociado a objetos llamado BRIDGE.
I. PATRÓN DE DISEÑO: BRIDGE

A continuación se encuentra la plantilla del patrón objeto de estudio:

1. Nombre del patrón: Bridge.

2. Clasificación del patrón: Estructural.

3. Intención: Desacoplar una abstracción de su implementación de manera que las dos puedan ser modificadas independientemente. La modificación de una no alterará el funcionamiento de la otra.

4. También conocido como: Handle/Body.

5. Motivación:

La herencia permite que una abstracción tenga varias implementaciones: esta relación se define en tiempo de compilación.

6. Aplicabilidad:

Este patrón se usa cuando:

•Se desea evitar un enlace permanente entre la abstracción y su implementación. Esto puede ser debido a que la implementación debe ser seleccionada o cambiada en tiempo de ejecución.
•Tanto las abstracciones como sus implementaciones deben ser extensibles por medio de subclases.
•Los cambios en la implementación de una abstracción no deben impactar en los clientes, es decir, su código no debe tener que ser recompilado.
•Para compartir una implementación entre múltiples objetos, sin que lo noten los clientes.


7. Estructura:


8. Participantes:

•Abstraction:define una interface abstracta. Mantiene una referencia a un objeto de tipo Implementor.
•RedefinedAbtraction:extiende la interface definida por Abstraction.
•Implementor:define la interface para la implementación de clases. Esta interface no se tiene que corresponder exactamente con la interface de Abstraction; de hecho, las dos interfaces pueden ser bastante diferente. Típicamente la interface Implementor provee sólo operaciones primitivas, y Abstraction define operaciones de alto nivel basadas en estas primitivas.
•ConcreteImplementor: implementa la interface de Implementor y define su implementación concreta.
•Client: Crea los objetos de tipo abstraction

9. Colaboraciones:

•Abstraction emite los pedidos de los clientes a su objeto Implementor
•Client crea los objetos de tipo Abstraction

10. Consecuencias:

1. Desacopla interface e implementación:
•Una implementación no es limitada permanentemente a una interface. La implementación de una abstracción puede ser configurada en tiempo de ejecución.
•Es posible a un objeto cambiar su implementación en tiempo de ejecución.
•Elimina las dependencias sobre la implementación en tiempo de compilación.
•Cambiar una clase de implementación no require recompilar la clase Abstraction ni sus clientes.
•El desacoplamiento fomenta las capas, que pueden conducir a un sistema mejor estructurado. La parte de alto nivel de un sistema sólo tiene que conocer Abstraction e Implementor.

2. Mejora la extensibilidad:
•Se puede extender las jerarquías de Abstraction e Implementor independientemente.

3. Esconde los detalles de la implementación a los clientes.

Favorece la división en niveles de un sistema. Los niveles superiores de un sistema solo tienen que conocer la abstracción y el implementador no el implementador concreto.



11. Implementación:

•Crear una clase abstracta Abstraction.
•Crear clases concretas que se extiendan de Abstraction.
•Crear una interface Implementor
•Crear clases concretas que implementen Implementor.
•Crear la clase cliente que llame los objetos.

12. Código de ejemplo:

public class Abstraccion
{
private Implementador implementador;
public void setImplementador(Implementador implementador)
{
this.implementador = implementador;
}
public Implementador getImplementador()
{
return implementador;
}
public void operacion()
{
implementador.operacion();
}
}

public class AbstraccionRefinada extends Abstraccion
{
public void operacion()
{
super.operacion();
}
}
public interface Implementador
{
public abstract void operacion();
}
public class ImplementacionA implements Implementador
{
public void operacion()
{
System.out.println("implementacion A");
}
}

public class ImplementacionB implements Implementador
{
public void operacion()
{
System.out.println("implementacion B");
}
}
public class ClienteBridge
{
public static void main(String arg[])
{
Abstraccion abstraction = new AbstraccionRefinada();
abstraction.setImplementador(new ImplementacionA());
abstraction.operacion();
}
}


13. Usos Conocidos:
•El AppKit de NeXT usa un Bridge en la visualización de diferentes tipos de imágenes.
•El DOM de KDE3 esta basado en un bridge (con otros patrones). Permite crear diferentes tipos de documentos usando la misma abstracción.
•El patrón Bridge se utiliza ampliamente en los sistemas gráficos de ventanas, así como aplicación de las bibliotecas y kits de desarrollo. Gamma proporciona una larga lista de usos conocidos. (Gamma, 1995, pp 160 - 161) Un ejemplo más reciente se puede demostrar a través de un somero examen de la ventana de Resumen de herramientas que se ha desarrollado junto con el desarrollo del lenguaje Java.
•Una de las características del lenguaje Java es que está diseñado para ejecutarse en una máquina virtual, que podrán realizarse a través de múltiples plataformas, lo que permite cierto desarrollo de la plataforma cruzada. El AWT proporciona una interfaz consistente para el desarrollo y proporciona común para todas las clases que normalmente se encuentran en un entorno gráfico de ventanas. Escribe el desarrollador de software para utilizar todas las interfaces de AWT. Sin embargo, cuando los programas Java se ejecutan en un sistema de acogida, la gráfica de los objetos que se señala son los componentes nativos de esa plataforma. Esto se trata del uso directo del patrón bridge. Es decir, los clientes interactúan (enviar las solicitudes), concretamente con la interfaz de AWT (abstracción). Obtener estas solicitudes tramitadas por el AWT Componentes pares de objetos asociados a través de la interfaz entre pares (ConcreteImplementation), que es nativo de la plataforma de ejecutar la aplicación. (Zukowski, 1997, pp 497 - 500).
•Un ejemplo más del patrón bridge en Java es la forma de conectar el aspecto y las capacidades incluidas en los componentes Swing. (JavaSoft, 1998) Estas capacidades dinámicas para permitir la modificación de la apariencia de los botones, marcos de ventanas, y otros objetos de interfaz gráfica. Esto se hace con la introducción de la interfaz de usuario administrador, a partir de la cual obtener los componentes Swing, la aplicación concreta detalles.

14. Patrones relacionados:

Este patrón se puede implementar con:

Bridge comparte algunos atributos y puede hacer uso de otros patrones de diseño. El patrón bridge puede hacer uso de un Abstract Factory para la creación y configuración. Además de esto, la estructura del patrón Bridge es muy similar a la estructura del patrón adapter.

REFERENCIAS
[1] García Pérez Baltasar. Desarrollo rápido de aplicaciones. Version PDF.
[2] Orjuela Luz Marina. Modelos de Programación: Patrones GOF 07. Universidad Distrital Francisco José de Caldas. 2006.
[3] Cuesta Carlos E. Patrones de Diseño. Ingeniería de software I. Universidad Rey Juan Carlos. Versión PDF.
[4] Romero Tapia Esteban. Ayudantía N° 6. Versión PDF.
[5] Herrera Mauricio, Navia Andrés. Bridge, Builder & Interpreter. Versión PDF.
[6] http://www.info-ab.uclm.es/asignaturas/42579/cap4/Estructural.htm
[7] http://www.cs.clemson.edu/~malloy/courses/patterns/bridge.html
[8] http://sourcemaking.com/design_patterns/bridge
[9] http://en.wikipedia.org/wiki/Bridge_pattern