设计模式7 - 桥接模式Bridge

Bridge Design Pattern

“Decouple an abstraction from its implementation so that the two can vary independently” is the intent for bridge design pattern as stated by GoF.

Bridge design pattern is a modified version of the notion of “prefer composition over inheritance”.

Problem and Need for Bridge Design Pattern

When there are inheritance hierarchies creating concrete implementation, you loose flexibility because of interdependence. Oops! these kind of sentencies shows that the author(I) didn’t understand and tries to escape! Okay, I will decrypt this sentence in the coming paragraphs.

Decouple implentation from interface and hiding implementation details from client is the essense of bridge design pattern.

Elements of Bridge Design Pattern

• Abstraction – core of the bridge design pattern and defines the crux. Contains a reference to the implementer.
• Refined Abstraction – Extends the abstraction takes the finer detail one level below. Hides the finer elements from implemetors.
• Implementer - This interface is the higer level than abstraction. Just defines the basic operations.
• Concrete Implementation – Implements the above implementer by providing concrete implementation.

Example for core elements of Bridge Design Pattern

Vehicle -> Abstraction
manufacture()

Car -> Refined Abstraction 1
manufacture()

Bike -> Refined Abstraction 2
manufacture()

Workshop -> Implementor
work()

Produce -> Concrete Implementation 1
work()

Assemble -> Concrete Implementation 2
work()

Generic UML Diagram for Bridge Design Pattern

Examples：

Before Bridge Design Pattern

After Bridge Design Pattern

Sample Java Code for Bridge Design Pattern

package designpattern;
/**
 * 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();
}
 
package designpattern;
 
/**
 * 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();
 
  }
 
}
 
package designpattern;
 
/**
 * 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();
  }
 
}
 
package designpattern;
 
/**
 * Implementor for bridge pattern
 * */
public interface Workshop {
  abstract public void work();
}
 
package designpattern;
 
/**
 * Concrete implementation 1 for bridge pattern
 * */
public class Produce implements Workshop {
 
  @Override
  public void work() {
    System.out.print("Produced");
  }
 
}
 
package designpattern;
 
/**
 * Concrete implementation 2 for bridge pattern
 * */
public class Assemble implements Workshop {
 
  @Override
  public void work() {
    System.out.println(" Assembled.");
  }
 
}
 
package designpattern;
 
/*
 * 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();
 
  }
}

Summary of Bridge Design Pattern

• Creates two different hierarchies. One for abstraction and another for implementation.
• Avoids permanent binding by removing the dependency between abstraction and implementation.
• We create a bridge that coordinates between abstraction and implementation.
• Abstraction and implementation can be extended separately.
• Should be used when we have need to switch implementation at runtime.
• Client should not be impacted if there is modification in implementation of abstraction.
• Best used when you have multiple implementations.

Output: