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()

Ads by Google

Generic UML Diagram for Bridge Design Pattern

Before Bridge Design Pattern

After Bridge Design Pattern

Sample Java Code for Bridge Design Pattern


package com.javapapers.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 com.javapapers.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 com.javapapers.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 com.javapapers.designpattern;

/**
 * Implementor for bridge pattern
 * */
public interface Workshop {
	abstract public void work();
}

package com.javapapers.designpattern;

/**
 * Concrete implementation 1 for bridge pattern
 * */
public class Produce implements Workshop {

	@Override
	public void work() {
		System.out.print("Produced");
	}

}

package com.javapapers.designpattern;

/**
 * Concrete implementation 2 for bridge pattern
 * */
public class Assemble implements Workshop {

	@Override
	public void work() {
		System.out.println(" Assembled.");
	}

}

package com.javapapers.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();

	}
}

Output:
Car Produced Assembled.
Bike Produced Assembled.

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.

Bridge Vs Adapter Design Pattern

The adapter design pattern helps it two incompatible classes to work together. But, bridge design pattern decouples the abstraction and implementation by creating two different hierarchies.

This Design Patterns tutorial was added on 05/02/2012.

«

»

68 Responses to “Bridge Design Pattern”

  1. Prabhakar says:

    Thanks for your work. neat explanation..

  2. Ishtiaque says:

    I really like your simple way of presentation. I am following your articles and will definitely come back whenever I need a quick refresh of the topic.

    Thank you,
    –Ishtiaque,

    • Ashish says:

      Thats true, i am C guy moving to C++ after many years working on C.
      Though all the examples are in java, i am able to understand all the design patterns.
      For a quick reading and grasping the concepts, these blogs are very useful.
      Please keep up the good work!

  3. Jayaraman says:

    Ya your article is very good

  4. sindhu says:

    Good One.

  5. cndhu says:

    Please explain cohesion and coupling

  6. pavan says:

    thank you for giving simple and clear explanation

  7. steven says:

    Simple and informative.
    Thanks.

  8. Tarsi says:

    Bridge Vs Abstract Design Pattern?
    Or
    Bridge Vs Adapter Design Pattern?

    Please do explain the difference between Bridge and Abstract Factory.

    Nice post by the way.

  9. Sayali says:

    VERY SIMPLE AND CLEAR IMPLEMENTATION

    Thanks.

  10. Joe says:

    Thanks Tarsi, fixed it.

  11. Eren says:

    Although I am very new to class designing concepts, the pattern explained above was very clear to me.
    Thanks for the good work.

  12. Anonymous says:

    joseph…very good one…..

  13. Anonymous says:

    anonymous —–hari….

  14. Anonymous says:

    Hi Joe,

    Is it right to add our name and the bug number when we do bug fix in java class or jsp files?

  15. Sidharth says:

    Keep on going you rock. !!!

  16. Ganesh says:

    Simplest explanation of Bridge Pattern I have ever read. Great Please keep writing.

  17. Nazmul says:

    Really happy after reading this article.
    Great job.
    Thanks.

  18. Gayathri says:

    brilliant brilliant.. i really understood bridge pattern by looking at the before and after images.. thanks so much!!

  19. Rajesh says:

    Very good explanation. Good work keep it up :)

  20. sivareddy says:

    class A{


    class B{


    }
    }
    above innerclass following which relationship in java?

  21. santhana says:

    Very good explanation

  22. ashwini says:

    Very nice article Joe.. Very well presented.Easy to understand.Keep up the good work :) thank u :)

  23. Anonymous says:

    HJ…simple and clear. give more examples on when to select this pattern.

    keep it up

  24. Anonymous says:

    I admire you

  25. Anonymous says:

    sir , you have written it so clearly, one can quickly get it , thankyou so much.

  26. Shashidhar says:

    Thanks for the neat explanation on this. I like the pictorial representation (vehicle – workshop), But I didn’t find example description. Can you add few lines describes on this diagram?

  27. ankur goel says:

    It does not seem logical that Vehicle has WorkShop.

    Instead I would have created a new Object of Produce and Assemble in manufacture function and called their work function with this as the argument.

  28. deva says:

    nice explanation..

  29. Anand says:

    Can this be refined to be more clear?. I feel that the way we produce and assemble car and bike would be totally different. Please correct me if I am wrong.

  30. Ramani says:

    I agree with Ankur. May be you can give a differnt example.
    In this example, I would also say that we create a Car or a Bike separately which implements Vehicle and pass it to the Workshop which accepts Vehicle type objects in its constructor.

  31. suhas says:

    Thanks a lot
    Really good article.
    It helps me a lot to understand the bridge design pattern

  32. Satih says:

    clear explanation …

  33. Anonymous says:

    Your example is wrong. Workshop HAS-A Vehicle, not the other way round.

  34. Anonymous says:

    Any update on the Behavioural patterns

    Anirban

  35. ravikumar dasu says:

    very good and very informative…easy to understand

  36. Umesh says:

    This is the only good example found so far by google :)

  37. Srinivas says:

    its really an excellent one.

  38. Davut Kamber says:

    your work is very simple and understandable, thank you for your brillant work.

  39. Yasser says:

    I see you use WordPress, your content definitely deserves a better theme.

  40. sravani says:

    thank you so much

  41. sravani says:

    thank you sir

  42. Hrishi says:

    Gud One !!

  43. Omar Salem says:

    Thank you, very informative ;)

  44. anonymous says:

    From this example the utility of bridge pattern is not clear. You have used same method to produce both car and as well as bike. Which is never a feasible option. You always need a different workshop for producing two different types of vehicles. Same holds for assemblers. Pardon me for this comment. We need a better real life example for this design pattern.

  45. narasimha says:

    Its very easy to understand..Thank u very much.

    Keep going ..:)

  46. Arun Abraham says:

    Amazing work. I am learning design patterns from your blog. Much easier to understand than the books. :)

  47. amit says:

    nice example…..thank…!!!

  48. bruno says:

    Hey Joe, thank you. I liked your “before” and “after” chart, that was very insightful.

  49. Said Naeem Shah says:

    very nice

  50. Manigandan says:

    very nice article. thanks.

  51. Constantin says:

    Another great article. Many thanks.

  52. An An says:

    Thank dear, It’s very good

  53. Priyanka says:

    Very good article. I Loved the use of simple examples to explain the patterns.

  54. Priyanka says:

    Very good article. I Loved the use of simple examples to explain the patterns.

  55. Niraj says:

    Explanation is crystal clear, content are awesome. Lots of praises for you.

    But the composition, Vehicle HAS-A Workshop does not suit here as a real life example. It should be other way around. Please explain or modify the example.

  56. Swarup says:

    oh joe, u made my day … Never ever found simple sentences explaining design patterns.

    Keep it up buddy…

  57. Anonymous says:

    Really clean explanation and very good tutorial on design patterns so far being found

  58. Sridhar says:

    Hi,

    A Car or bike can be either produced or assembled.

    From your example I see that we are passing 2 different implementations to the constructor of the Refined abstraction (Car and Bike).

    In you test class BridgePattern you have instantiated a Car and Bike using the Abstraction class Vehicle. Also, the manufacture method is invoked on both the cases.

    What I do not understand is. How will I be able to change the implementation(manufacturing) from say assembling to producing or to something new.

    Also, After I make that change how will I be able invoked it from the Test Class, without impacting the bike and car classes.

  59. Venkatraman AP says:

    Joe,

    The core concept of this pattern has not yet been given by your explanation. Not only by you, even in GoF book also the same. Bridge pattern says that decouple an abstraction from its implementation so that the two can vary independently.

    If either abstraction or its implementation or both will be changed, what would be result is not given.

  60. Vakshu says:

    I feel the clarity or preciseness of the content is missing. Could you please take extra care in specifying relationships.
    ex: After bridge pattern example of car, bike produce.
    Inheritence and composition is not specified clearly.

  61. Ganesh Adapa says:

    Vehicle, workshop example can be solved easily using Strategy pattern and IMO, strategy pattern is the best fit for this problem.
    I’m still trying to understand where can bridge pattern be applied. Anyone demonstrating it with good example will be a great help.

  62. Ramasubramani N says:

    Excellent article !!! Many thanks to you !!!

  63. Vishakha Thatte says:

    Really nice article Joe

  64. Prashant says:

    Joe, though the definition of Bridge pattern is right but I have concerns over applicability of this pattern on the cited example.

    In your whiteboard diagram for “design before bridge pattern”, the purpose of creating two subclasses of car: ProduceCar & AssembleCar is not clear. It would be better if you can explain the example properly.

    Without understanding why would that design was done in first place, it’s very difficult to appreciate the application of design pattern on this example.

Leave a Reply