Application Development, Product to Market
  • Home
  • Notes
  • Projects
  • Resources
    • Discovery Log
    • Books I Read
    • Blogs I Visit
    • Tools I Use
  • Home
  • Notes
  • Projects
  • Resources
    • Discovery Log
    • Books I Read
    • Blogs I Visit
    • Tools I Use

Bridge Design Pattern Example

10/16/2013

0 Comments

 
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. 
Picture
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:
Picture
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
0 Comments



Leave a Reply.

    Categories

    All
    Algorithm
    Concurrency
    CQ
    Data Structure
    Design Pattern
    Developer Tool
    Dynamic Programming
    Entrepreneur
    Functional Programming
    IDE
    Java
    JMX
    Marketing
    Marklogic
    Memory
    OSGI
    Performance
    Product
    Product Management
    Security
    Services
    Sling
    Social Media Programming
    Software Development

    Feed Widget

    Archives

    May 2020
    March 2020
    April 2018
    March 2018
    February 2018
    December 2017
    March 2017
    November 2016
    June 2016
    May 2016
    April 2016
    October 2015
    September 2015
    August 2015
    September 2014
    July 2014
    June 2014
    May 2014
    March 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013

    RSS Feed

in loving memory of my mother  and my 4th aunt
Photos used under Creative Commons from net_efekt, schani, visnup, Dan Zen, gadl, bobbigmac, Susana López-Urrutia, jwalsh, Philippe Put, michael pollak, oskay, Creative Tools, Violentz, Kyknoord, mobilyazilar