Patrón de diseño de puente

¡Hola! Ahora continuamos profundizando en un tema útil extenso y súper importante: los patrones de diseño. Hoy vamos a hablar sobre el patrón del puente. Al igual que otros patrones, el patrón puente sirve para resolver los problemas típicos que encuentra un desarrollador al diseñar la arquitectura del software. Hoy estudiemos las características de este patrón y descubramos cómo usarlo.

¿Qué es el patrón del puente?

El patrón de puente es un patrón de diseño estructural. En otras palabras, su trabajo principal es crear una estructura completa a partir de clases y objetos. Un puente hace esto dividiendo una o más clases en jerarquías separadas: abstracción e implementación . Un cambio en la funcionalidad de una jerarquía no implica un cambio en la otra. Eso está muy bien, pero esta definición es muy amplia y no responde a la pregunta más importante: "¿Qué es el patrón del puente?" Creo que te será más fácil entender su aplicación práctica. Entonces, vamos a crear un escenario clásico para el patrón del puente. Tenemos una Shapeclase abstracta, que representa una figura geométrica genérica:

• Forma.java

  
  public abstract class Shape {
     public abstract void draw();
  }
  

  Cuando decidamos agregar formas como triángulos y rectángulos, haremos que hereden la Shapeclase:

• Rectángulo.java:

  
  public class Rectangle extends Shape {
     @Override
     public void draw() {
         System.out.println("Drawing rectangle");
     }
  }
  

• Triángulo.java:

  
  public class Triangle extends Shape {
     @Override
     public void draw() {
         System.out.println("Drawing triangle");
     }
  }
  

Todo parece sencillo hasta el momento en que introducimos el concepto de color. Es decir, cada forma tendrá su propio color y la funcionalidad del draw()método dependerá de este color. Para tener diferentes implementaciones del draw()método, necesitamos crear una clase para cada combinación de forma y color. Si tenemos tres colores, entonces necesitamos seis clases: TriangleBlack, TriangleGreen, TriangleRed, y . Seis clases no es un gran problema. ¡Pero! Si necesitamos agregar una nueva forma o color, entonces el número de clases crece exponencialmente. ¿Cómo salir de esta situación? Almacenar el color en un campo y enumerar todas las opciones usando sentencias condicionales no es la mejor solución. Una buena solución es mover el color a una interfaz separadaRectangleBlackRectangleGreenRectangleRed. Dicho y hecho: vamos a crear una Colorinterfaz con tres implementaciones: BlackColor, GreenColory RedColor:

• Color.java:

  
  public interface Color {
     void fillColor();
  }
  

• BlackColor.java:

  
  public class BlackColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in black color");
     }
  }
  

• GreenColor.java

  
  public class GreenColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in green color");
     }
  }
  

• RedColor.java

  
  public class RedColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in red color");
     }
  }
  

  Ahora agregamos un Colorcampo a la Shapeclase. Obtendremos su valor en el constructor.

• Forma.java:

  
  public abstract class Shape {
     protected Color color;
    
     public Shape(Color color) {
         this.color = color;
     }
  
     public abstract void draw();
  }
  

  Usaremos la colorvariable en Shapeimplementaciones. Esto significa que las formas ahora pueden usar la funcionalidad de la Colorinterfaz.

• Rectángulo.java

  
  public class Rectangle extends Shape {
  
     public Rectangle(Color color) {
         super(color);
     }
  
     @Override
     public void draw() {
         System.out.println("Drawing rectangle");
         color.fillColor();
     }
  }
  

Ta-da! Ahora podemos crear diferentes colores y formas hasta el infinito, y el número de clases aumentará solo de forma lineal. El Color colorcampo es un puente que conecta dos jerarquías de clases separadas.

Cómo construir un puente: abstracción e implementación

Veamos un diagrama de clases que representa el patrón de puente: aquí puede ver dos estructuras independientes que se pueden modificar sin afectar la funcionalidad de la otra. En nuestro caso:

• La abstracción es la Shapeclase.
• RefinedAbstraction es las clases TriangleyRectangle
• Implementador es la Colorinterfaz
• ConcreteImplementor es el BlackColor, GreenColory RedColorlas clases.

La Shapeclase es una abstracción: un mecanismo para administrar el relleno de formas con varios colores, que se delega en la Colorinterfaz (Implementor). Las clases Triangley Rectangleson clases concretas que utilizan el mecanismo puesto a disposición por la Shapeclase. BlackColory GreenColorson RedColorimplementaciones concretas en la jerarquía de implementación.

Dónde usar el patrón de puente

Una gran ventaja de usar este patrón es que puede realizar cambios en las clases funcionales en una jerarquía sin romper la lógica de la otra. Además, este enfoque ayuda a reducir el acoplamiento entre clases. El requisito principal al usar este patrón es "siga las instrucciones", ¡no ignore ninguna de ellas! Con ese fin, averigüemos las situaciones en las que definitivamente debería usar el patrón de puente:

1. Si necesita ampliar el número de entidades en base a combinaciones de dos conceptos (por ejemplo, formas y colores).

2. Si desea dividir una clase grande que no cumple con el principio de responsabilidad única en clases más pequeñas que tienen una funcionalidad limitada.

3. Si es necesario realizar cambios en la lógica de ciertas entidades mientras se ejecuta el programa.

4. Si es necesario ocultar una implementación a los clientes de la clase o biblioteca.

Cuando use este patrón, recuerde siempre que agrega entidades adicionales a su código; puede que no tenga sentido usarlo en un proyecto donde solo hay una forma y uno o dos colores posibles.

Pros y contras del patrón.

Al igual que otros patrones, un puente tiene ventajas y desventajas. Ventajas del patrón de puente:

1. Mejora la escalabilidad del código: puede agregar funcionalidad sin temor a romper algo en otra parte del programa.
2. Reduce el número de subclases cuando el número de entidades estaría basado en combinaciones de dos conceptos (por ejemplo, formas y colores).
3. Hace posible trabajar por separado en dos jerarquías separadas: Abstracción e Implementación. Dos desarrolladores diferentes pueden realizar cambios sin profundizar en los detalles del código del otro.
4. Reduce el acoplamiento entre clases: el único lugar donde se acoplan las dos clases es el puente (es decir, el Color colorcampo).

Desventajas del patrón de puente:

1. Según la situación específica y la estructura general de un proyecto, podría afectar negativamente el rendimiento de un programa (por ejemplo, si necesita inicializar más objetos).
2. Hace que el código sea menos legible debido a la necesidad de cambiar entre las dos clases.

Diferencia del patrón de estrategia

El patrón del puente a menudo se confunde con otro patrón de diseño: la estrategia. Ambos usan composición (aunque usamos agregación en el ejemplo con figuras y colores, el patrón Bridge también puede usar composición), delegando el trabajo a otros objetos. Pero hay una diferencia entre ellos, y es enorme. El patrón de estrategia es un patrón de comportamiento: resuelve problemas completamente diferentes. La estrategia permite intercambiar algoritmos, mientras que el puente separa una abstracción de las implementaciones para elegir entre diferentes implementaciones. En otras palabras, a diferencia de una estrategia, un puente se aplica a entidades completas o estructuras jerárquicas. El patrón de puente puede ser una buena arma en el arsenal de un desarrollador. Lo principal es identificar las situaciones en las que vale la pena usarlo y reconocer cuándo es apropiado algún otro patrón.

• único
• Fábrica
• Fábrica abstracta
• método de fábrica
• Apoderado
• Adaptador