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

Car -> Refined Abstraction 1

Bike -> Refined Abstraction 2

Workshop -> Implementor

Produce -> Concrete Implementation 1

Assemble -> Concrete Implementation 2

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

	public void manufacture() {
		System.out.print("Car ");;;



package com.javapapers.designpattern;

 * Refine abstraction 2 in bridge pattern
public class Bike extends Vehicle {

	public Bike(Workshop workShop1, Workshop workShop2) {
		super(workShop1, workShop2);

	public void manufacture() {
		System.out.print("Bike ");;;


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 {

	public void work() {


package com.javapapers.designpattern;

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

	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());
		Vehicle vehicle2 = new Bike(new Produce(), new Assemble());


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.

previous post: Facade Design Pattern

next post: Java Class Loader

66 comments on “Bridge Design Pattern

  1. Thanks for your work. neat explanation..

  2. 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,

    • 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. thank you for giving simple and clear explanation

  4. Bridge Vs Abstract Design Pattern?
    Bridge Vs Adapter Design Pattern?

    Please do explain the difference between Bridge and Abstract Factory.

    Nice post by the way.



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

  7. Hi Joe,

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

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

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

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

  11. Very good explanation. Good work keep it up :)

  12. class A{

    class B{

    above innerclass following which relationship in java?

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

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

    keep it up

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

  16. 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?

  17. 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.

  18. 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.

  19. 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.

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

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

  22. Any update on the Behavioural patterns


  23. very good and very informative…easy to understand

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

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

  26. 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.

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

    Keep going ..:)

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

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

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

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

  32. 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.

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

    Keep it up buddy…

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

  35. 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.

  36. 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.

  37. 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.

  38. 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.

  39. Excellent article !!! Many thanks to you !!!

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>