Since
2008
Since
2008
Since
2008
“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”.
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.
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()
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.
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.
Comments are closed for "Bridge Design Pattern".
Thanks for your work. neat explanation..
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,
Ya your article is very good
Good One.
Good Example.
Please explain cohesion and coupling
thank you for giving simple and clear explanation
Simple and informative.
Thanks.
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.
VERY SIMPLE AND CLEAR IMPLEMENTATION
Thanks.
Thanks Tarsi, fixed it.
Although I am very new to class designing concepts, the pattern explained above was very clear to me.
Thanks for the good work.
joseph…very good one…..
anonymous —–hari….
Hi Joe,
Is it right to add our name and the bug number when we do bug fix in java class or jsp files?
Keep on going you rock. !!!
Simplest explanation of Bridge Pattern I have ever read. Great Please keep writing.
Really happy after reading this article.
Great job.
Thanks.
brilliant brilliant.. i really understood bridge pattern by looking at the before and after images.. thanks so much!!
Very good explanation. Good work keep it up :)
class A{
—
—
class B{
—
—
}
}
above innerclass following which relationship in java?
Very good explanation
Very nice article Joe.. Very well presented.Easy to understand.Keep up the good work :) thank u :)
HJ…simple and clear. give more examples on when to select this pattern.
keep it up
good
I admire you
sir , you have written it so clearly, one can quickly get it , thankyou so much.
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?
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.
nice explanation..
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.
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.
Thanks a lot
Really good article.
It helps me a lot to understand the bridge design pattern
clear explanation …
Your example is wrong. Workshop HAS-A Vehicle, not the other way round.
Any update on the Behavioural patterns
Anirban
very good and very informative…easy to understand
This is the only good example found so far by google :)
its really an excellent one.
your work is very simple and understandable, thank you for your brillant work.
I see you use WordPress, your content definitely deserves a better theme.
thank you so much
thank you sir
Gud One !!
Thank you, very informative ;)
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.
Its very easy to understand..Thank u very much.
Keep going ..:)
Amazing work. I am learning design patterns from your blog. Much easier to understand than the books. :)
nice example…..thank…!!!
Hey Joe, thank you. I liked your “before” and “after” chart, that was very insightful.
very nice
very nice article. thanks.
Another great article. Many thanks.
Thank dear, It’s very good
Very good article. I Loved the use of simple examples to explain the patterns.
Very good article. I Loved the use of simple examples to explain the patterns.
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.
oh joe, u made my day … Never ever found simple sentences explaining design patterns.
Keep it up buddy…
Really clean explanation and very good tutorial on design patterns so far being found
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.
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!
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.
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.
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.
Excellent article !!! Many thanks to you !!!
Really nice article Joe
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.