Patrón Bridge

Objetivo:

“Desacoplar una abstracción de su implementación de modo que los dos puedan ser modificados de forma independiente.”

Diagrama de clases genérico 

¿Por qué Bridge?

Este patrón a simple vista es complicado de entender, en parte porque no existe una relación clara entre su nombre y su descripción como en otros patrones tales como el adapter adapta, el builder construye… Mientras que se le dice Bridge porque actúa de puente entre la clase que refina la abstracción y las implementaciones de la interfaz. Parte de nuestro código estará implementado dentro de nuestra clase RefinamientoAbstraccion, y parte estará fuera, bien sea en el ImplementorConcretoA o en el ImplementorConcretoB. Accediendo de modo que cuando parte del código de nuestra clase RefinamientoAbstraccion realice una operación cuyo código no dependa de sí misma, solicite la realización de esta al elemento que se encuentra al otro lado.

¿Cuándo utilizar Bridge?

Las situaciones óptimas en los que se debe utilizar este patrón serán:

• Cuando se desea evitar un enlace permanente entre la abstracción y (toda o parte de) su implementación.
• Cuando los cambios en la implementación de una abstracción no debe afectar a las clases que hace uso de ella.
• Cuando se desea compartir una implementación entre múltiples objetos.

     Ejemplo
      Descargar proyecto Aquí

      Se requiere crear unos vehículos que podrán evolucionar independientemente del motor que posean, para efectos del ejemplo se mostrara el código en java.
     
      Nuestra abstracción simbolizará el vehículo en sí, mientras que la parte que se tenderá “al otro lado del puente” será el motor del mismo.

    Diagrama UML del Implementor

      Comenzaremos codificando la interfaz Implementor, que en nuestro ejemplo estará representada por el motor es decir IMotor.

Seguidamente codificamos lo tipos de motor por medio de las clases diésel y gasolina que harán las veces de ImplementorConcretoA e ImplementorConcretoB respectivamente.

    Diagrama UML de la Abstracción

Continuamos codificando la abstracción que estaría representada por la clase Vehículo, aplicando el principio de inversión de dependencia, el quinto de los principios SOLID, le inyectamos en el constructor el objeto que implementara el motor, desacoplando mas la abstracción de la interfaz que se realizo por medio composición al declarar el atributo motor de tipo IMotor

Ahora codificamos lo tipos de motor por medio de las clases Berlina y Monovolumen que harán las veces de RefinamientoAbstraccionA e RefinamientoAbstraccionB respectivamente.

    Diagrama UML Completo