Bridge Design Pattern Example

Bridge pattern is categorized as a structural pattern in GoF because it structurally decouples abstraction from its implementation so that the two can vary independently. However, it is very similar to Strategy pattern which is categorized as a behavioral pattern. 

source: GoF

overview

Instead of having one abstract class that defines the interface to the abstraction and its concrete subclasses implement it in different ways all in one class hierarchy, bridge pattern separates implementation from domain abstraction so either side can be reused or extended independently with respect to its own inheritance hierarchy:

Domain Abstraction encapsulates (has a reference or references to) multiple Implementations and can initialize theseImplementation instances via the constructor. As a result, you may have any combination of different Abstraction and Implementations.

For example, an image format class like JPG or PMG is on the Abstraction side, whereas displaying on Widows or Mac is on the Implementor side. The association from Abstraction to Implementation is a 'basic aggregation' (as opposed to composition aggregation) which means the Part Class (Implementation) instances can outlive its Whole Class (Abstraction).

code example

/**
 * abstraction in bridge pattern
 * */
abstract class Vehicle {
  protected Workshop workShop1;
  protected Workshop workShop2;
 
  protected Vehicle(Workshop workShop1, Workshop workShop2) {
    this.workShop1 = workShop1;
    this.workShop2 = workShop2;
  }
 
  abstract public void manufacture();
}

/**
 * Refine abstraction 1 in bridge pattern
 */
public class Car extends Vehicle {
 
  public Car(Workshop workShop1, Workshop workShop2) {
    super(workShop1, workShop2);
  }
 
  @Override
  public void manufacture() {
    System.out.print("Car ");
    workShop1.work();
    workShop2.work();
  } 
}
  
/**
 * Refine abstraction 2 in bridge pattern
 */
public class Bike extends Vehicle { 
  public Bike(Workshop workShop1, Workshop workShop2) {
    super(workShop1, workShop2);
  }
 
  @Override
  public void manufacture() {
    System.out.print("Bike ");
    workShop1.work();
    workShop2.work();
  } 
}
 
/**
 * Implementor for bridge pattern
 * */
public interface Workshop {
  abstract public void work();
}
 
/**
 * Concrete implementation 1 for bridge pattern
 * */
public class Produce implements Workshop { 
  @Override
  public void work() {
    System.out.print("Produced");
  } 
}
  
/**
 * Concrete implementation 2 for bridge pattern
 * */
public class Assemble implements Workshop { 
  @Override
  public void work() {
    System.out.println(" Assembled.");
  } 
}
 
/*
 * Demonstration of bridge design pattern
 */
public class BridgePattern {
 
  public static void main(String[] args) {
    Vehicle vehicle1 = new Car(new Produce(), new Assemble());
    vehicle1.manufacture();
    Vehicle vehicle2 = new Bike(new Produce(), new Assemble());
    vehicle2.manufacture();
  }
}

when to use bridge pattern

• You have a monolithic class structure to split into 2 class hierarchies. 
  
• An Abstraction has multiple Implementations. 
• You want to avoids permanent binding by removing the dependency between Abstraction and Implementation.
• Need to switch implementation at run-time. (as in the case of Strategy)

comparison

Bridge vs. Strategy (very similar)

• Same UML, different intents.
• Bridge's intent is to decouple an abstraction from its implementations so that the two sides can vary independently, whereas Strategy's intent stresses making  only one algorithm/implementation interchangeable.
• There is massive subclassing going on the Abstraction side and the nature of the Abstraction methods are more compositional, adaptive and far reaching, whereas Strategy has just a simple strategy delegation.
• Bridge is classified under structural pattern, whereas Strategy is classified as a behavioral pattern.
• Bridge's Implementor classes are named with noun; whereas Strategy classes are named with a verb or a noun that describe action.

references

• Bridge Pattern