Welcome to my Bridge Design Pattern tutorial. If you ever wanted to build a group of classes that slowly added functionality from one class to the next, this is the design pattern for you.

There seems to be a lot of confusion in regards to what constitutes a bridge design pattern in both books as well as online. In this tutorial I will show you how it was explained to me and the ways in which I have found it is useful.

The code after the video goes into greater detail if you’d like to check that out.

// Refined Abstraction
// If I decide I want to further extend the remote I can
public class TVRemoteMute extends RemoteButton{
public TVRemoteMute(EntertainmentDevice newDevice) {
super(newDevice);
}
public void buttonNinePressed() {
System.out.println("TV was Muted");
}
}

TVREMOTEPAUSE.JAVA

// Refined Abstraction
// If I decide I want to further extend the remote I can
public class TVRemotePause extends RemoteButton{
public TVRemotePause(EntertainmentDevice newDevice) {
super(newDevice);
}
public void buttonNinePressed() {
System.out.println("TV was Paused");
}
}

You’re very welcome 🙂 Thank you for stopping by my little site. Yes the remote is acting like a universal remote. As per your question about composition versus aggregation. With composition the contained object can’t exist without the containing object. Based off of that, yes you are correct that the entertainment device can exist without the remote. Thank you for pointing that out and I will change the code

Nice way to explain Bridge pattern. However, I just have 2 points to make, and would appreciate your thoughts.

1) In example above, I find it difficult to digest that I can create a TVRemote and can pass it a DVDDevice. The code will still work.

So shouldn’t the constructor be changed so that a TVRemote can only take in a TVDevice, and similarly for the DVDRemote.

2) Would it perhaps make the example slightly better if we did this instead?

You extend the EntertainmentDevice to create TVDevice. Every TVDevice provides functionality of muting and pausing.

Then you create specific Remotes to choose what the button nine does. So for a tvRemotePause.buttonNinePressed() will actually call the device.pause(), and tvRemoteMute.buttonNinePressed() will call the device.mute().

You are understanding the pattern and I like your ideas. Understand that I try to focus in and explain the pattern rather then try to optimize the code completely. Design patterns aren’t exactly recipes, but instead they are guides to follow. It says this much in the GOF book, but I can’t find the quote right now. Either way you are getting the idea

Great video! My respect for you increases with each video I see. Simply tremendous!
One request though, if you could provide diagrams like those given for Abstract Factory and Factory method Patterns, it would greatly help us to visualise the patterns and grasp the code more quickly.

Thank you very much for this tutorial, the concept of brigde is getting clearer.

I have a question in DVDRemote there is an attribute “play”, it is not clear to me why would a Remote have “play” instead should it be in the Device?
Assuming “play” would instead be in the EntertainmentDevice.
Then could the DVDRemote have following code
public void buttonNinePressed() {
newDevice.toggelPlay();
System.out.println(“DVD is Playing: ” + newDevice.isPlaying());
}

Thank you for training video its very helpful and your previous replies too.

In the definition of Bridge..its stated
“Bridge is designed up-front to let the abstraction and the implementation vary independently”
I do not understand what does “abstraction” mean ? Can you help me .

Basically by abstracting we try to keep the user from needing to understand the details. So here we have a remote control. So, if they want to have something different occur when button 9 is pressed for example they just extend RemoteButton and define a new buttonNinePressed method and it will just work.

Good code can be changed without breaking, or without needing to change anything else. Abstraction helps us do that. i hope that helps.

Hello Derik,
First of all I want to tell you that I really like your tutorials, they’ve been very helpful to me, you are brilliant.
I have a little question about the bridge pattern and the remote example, I don’t know if I’m missing something, but shouldn’t the remote interface has all the methods in the entertainmentDevice class?!!!
I mean what if I want to press the seven and eight buttons using a TVRemoteMute object?

thanks for your great explantion. However, something I have not yet understood – why is it that you implement
– TVRemoteMute
– TVRemotePause
(and probably also a – not shown here – DVDRemoteMute and a DVDRemotePause)
instead of a more general RemoteMute and a RemotePause?
In the latter cause, this would add the flexibility
to – at runtime – combine 2 Devices with 2 Different
Remote-Types, and as such beeing able to dynamically create
4 Different Combinations – like:

I also read the (rather short) explantion in Head-First-Design-Patterns –
and Kathy describes the pattern just like you did – so if I don’t (automatically)
trust you (hey, I don’t know you! ;-), at least I am trusting Java-God Kathy Sierra, which means your explanation
of the pattern must also be correct – I just don’t understand why to limit a pattern, if it could be so much more dynamic, the other way round.
(And I am sure, if I didn’t get that part, I didn’t get the true entire meaning of the pattern either).

p.s. Thinking about it, I guess I have done something like the Strategy-Pattern – However this knowledge still does not answer my question (then I could define the question as- of why I would use the Bridge Pattern istead of the Strategy-Pattern).

Last but not least – it’s said (Internet, Head First book) the bridge pattern would separate Abstraction from it’s implementation – well thinking of abstraction and implementation, I would think of something like “AbstractCar and concrete BMW extends AbstractCar” – however (in your bridge-pattern example) – the abstraction is like a real-world-abstraction – a remote control ABSTRACTS the use of the TV, but a remote control is not an abstraction of a TV.
?????? sorry, I am really confused now… ??????

Patterns confuse everyone in the beginning. The strategy pattern is used when you have many ways of doing one thing. It also allows you to decide how to do them at runtime. In my tutorial on it I show how we can change the flying abilities of an animal at runtime.

The bridge pattern allows me to add additional functionality easily. Here I have a remote that can easily be changed to work with not only tvs, but any other type of electronics device.

well, from what I’ve found out so far, the bridge pattern and the strategy pattern actually are / seem to be the exact same pattern, the very few comments about it I found on internet forums say it would depend on the context / motivation of what is actually required – if you want to replace functionality at runtime – it’s called the strategy pattern, if you want to separate implementation and interface, it’s the bridge pattern. However it’s still not 100% clear to me why this would justify two distinct names for technically the same thing. Hmmmm.