¿Qué es el patrón de diseño del puente?

Según las definiciones de GOF, el patrón de puente "separa una abstracción de su implementación para que los dos puedan variar de forma independiente"

En el patrón de diseño de puente, hay dos capas.

La primera capa es la capa de Abstracción.

y la segunda capa es la capa de implementación.

Si realizo algún cambio en la capa de implementación, no afectará a la capa de abstracción.

Del mismo modo, si realizo algún cambio en la capa de abstracción, no afectará a la capa de implementación.

Diagrama de clase del patrón de diseño de puente:

Como se muestra en el diagrama anterior, el patrón de diseño del puente consta de cuatro componentes. Son los siguientes:

Implementador :
esta es una interfaz que debe ser implementada por todas las clases de implementación. Esta interfaz actuará como un puente entre la clase de abstracción y la clase de implementación.

ConcreteImplementationA / ConcreteImplementaionB :
Estas son clases que implementan el Implementador. Estas clases contienen la implementación concreta de todas las operaciones.

Abstracción :

Esta va a ser una clase abstracta. que define los métodos para que llame el código del cliente. esta clase abstracta contiene una variable de implementador protegida que contiene una referencia al objeto que realiza la implementación.

ConcreteAbstraction / RefinedAbstraction :
estas son clases que se heredan de la clase abstracta Abstraction.

Comprender el patrón de diseño del puente con un ejemplo:

Supongamos que queremos (producir y ensamblar) autos nuevos de los siguientes dos tipos (BMW o Mercedes).

para ello necesitamos un taller de cada tipo para implementar las dos tareas anteriores (producir y ensamblar).

Entonces, el diagrama de clases para nuestro ejemplo será como el siguiente:

Implementación:

¿Cuándo necesitamos usar Bridge Design Pattern en aplicaciones en tiempo real?

Necesitamos usar el patrón de diseño de puente en aplicaciones en tiempo real, cuando:
1- Queremos ocultar los detalles de implementación del cliente.
2- Queremos que la selección o cambio de la implementación sea en tiempo de ejecución en lugar de en tiempo de diseño.
3- Queremos que tanto las clases de abstracción como las de implementación sean extensibles por las subclases.
4- Queremos evitar un vínculo de acoplamiento estrecho entre una abstracción y su implementación.
5- Los cambios en la implementación de una abstracción no deben tener impacto en los clientes.

Enlace de código completo en Github:

Patrones de diseño estructural/DP de 4 puentes