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.



Comments on “Bridge Design Pattern”

  1. Prabhakar

    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,

    • Ashish

      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

    Ya your article is very good

  4. sindhu

    Good One.

  5. cndhu

    Please explain cohesion and coupling

  6. pavan

    thank you for giving simple and clear explanation

  7. steven

    Simple and informative.

  8. Tarsi

    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.

  9. Sayali



  10. Joe

    Thanks Tarsi, fixed it.

  11. Eren

    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

    joseph…very good one…..

  13. Anonymous

    anonymous —–hari….

  14. Anonymous

    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

    Keep on going you rock. !!!

  16. Ganesh

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

  17. Nazmul

    Really happy after reading this article.
    Great job.

  18. Gayathri

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

  19. Rajesh

    Very good explanation. Good work keep it up :)

  20. sivareddy

    class A{

    class B{

    above innerclass following which relationship in java?

  21. santhana

    Very good explanation

  22. ashwini

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

  23. Anonymous

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

    keep it up

  24. Anonymous

    I admire you

  25. Anonymous

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

  26. Shashidhar

    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

    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

    nice explanation..

  29. Anand

    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

    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

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

  32. Satih

    clear explanation …

  33. Anonymous

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

  34. Anonymous

    Any update on the Behavioural patterns


  35. ravikumar dasu

    very good and very informative…easy to understand

  36. Umesh

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

  37. Srinivas

    its really an excellent one.

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

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

  40. sravani

    thank you so much

  41. sravani

    thank you sir

  42. Hrishi

    Gud One !!

  43. Omar Salem

    Thank you, very informative ;)

  44. anonymous

    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

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

    Keep going ..:)

  46. Arun Abraham

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

  47. amit

    nice example…..thank…!!!

  48. bruno

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

  49. Said Naeem Shah

    very nice

  50. Manigandan

    very nice article. thanks.

  51. Constantin

    Another great article. Many thanks.

  52. An An

    Thank dear, It’s very good

  53. Priyanka

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

  54. Priyanka

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

  55. Niraj

    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. oh joe, u made my day … Never ever found simple sentences explaining design patterns.

    Keep it up buddy…

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

  58. Sridhar


    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


    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

    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

    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

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

  63. Vishakha Thatte

    Really nice article Joe

  64. Prashant

    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.

Your Comment