1. El Problema que Resuelve (Motivación)

Cuando una abstracción puede tener varias implementaciones posibles, la tendencia habitual es recurrir a la herencia Sin embargo, la herencia vincula una implementación a la abstracción de forma permanente, lo que dificulta modificar, extender o reutilizar ambas partes por separado.

Considera el desarrollo de una interfaz de usuario portable con una clase base Window que deba funcionar en distintos sistemas de ventanas, como X Window e IBM Presentation Manager (PM)

Explosión de clases: Si se extiende la abstracción Window para crear una ventana especializada como IconWindow, la herencia obliga a implementar subclases específicas para cada plataforma (XIconWindow y PMIconWindow). Con cada nueva plataforma o tipo de ventana, el número de clases se multiplica exponencialmente.

Acoplamiento directo: El código cliente queda acoplado a plataformas concretas al instanciar directamente las subclases de una implementación específica, lo que complica la portabilidad La solución del Patrón Bridge: Separa la jerarquía de la interfaz del usuario (las abstracciones) de la jerarquía de las implementaciones del sistema operativo.

2. Estructura y Participantes

El patrón divide el objeto en dos partes mediante un puente (bridge)

Abstraction (Window): Define la interfaz de la abstracción y mantiene una referencia a un objeto de tipo Implementor

RefinedAbstraction (IconWindow, TransientWindow): Extiende y especializa la interfaz definida por Abstraction

Implementor (WindowImp): Define la interfaz para las clases de implementación

Esta interfaz suele dar solo operaciones básicas sobre las cuales Abstraction construye operaciones más complejas

ConcreteImplementor (XWindowImp, PMWindowImp): Implementa la interfaz de Implementor con código específico para cada entorno o plataforma.

3. Cuándo Aplicar el Patrón Bridge

El libro del Gang of Four recomienda utilizar el Patrón Bridge en los siguientes casos

Cuando se quiere evitar un enlace permanente entre una abstracción y su implementación (por ejemplo, si la implementación debe seleccionarse o cambiarse en tiempo de ejecución)

Cuando tanto las abstracciones como las implementaciones deben ser extensibles mediante subclases de forma independiente

Cuando los cambios en la implementación de una abstracción no deben tener impacto en los clientes (evitando la necesidad de recomputar o recompilar su código)

Cuando existe una proliferación desmedida de clases resultante de jerarquías anidadas

Cuando se desea compartir una implementación entre múltiples objetos de forma transparente para el cliente.

4. Consecuencias y Beneficios

Desacoplamiento de interfaz e implementación: La implementación no está vinculada permanentemente a la interfaz, lo que permite configuraciones o cambios en tiempo de ejecución y elimina dependencias de compilación . Mejora de la extensibilidad: Se pueden extender las jerarquías de Abstraction e Implementor independientemente . Ocultación de detalles de implementación: Los clientes quedan totalmente aislados de la representación interna de los objetos y mecanismos como el conteo de referencias o la gestión de plataformas

5. Relación con Otros Patrones

Bridge vs. Adapter: Aunque tienen estructuras similares (ambos usan la delegación hacia otro objeto), su intención es distinta . Adapter hace que dos clases incompatibles funcionen juntas después de haber sido diseñadas, mientras que Bridge diseña las abstracciones e implementaciones por separado desde el inicio para que evolucionen independientemente . Abstract Factory: Un patrón Abstract Factory puede ser utilizado para crear y configurar una instancia concreta de un Bridge según la plataforma activa .