Design patterns: Bridge

Hello everyone! Today topic is about the Bridge design pattern however, we will change some form of the entry into a more structured one, so let’s get to the topic 🙂



  • Separates abstractions from implementation.
  • The classes are not supposed to know about themselves.


The problem that it solves:

  • The possibilities of the class are greater (m.i.n by inheritance)
  • We maintain the principle of hermetization
  • The modules are independent of each other
  • The client does not see the implementation, so when we changing the implementation, we will not have to change the interface.


Use when:

  • You have many classes that inherit from the abstract class.
  • We want to separate the implementation from the client.
  • You must plan the class hierarchy.
  • You want to split the implementation between multiple objects.

Also when:

Then the Bridge pattern allows you to change to:

So we use the composition.



As the saying goes “Composition over inheritance“. Is it true? In some cases, yes, if it is as in the example above, we have a lot of derived classes in this example:

It’s better to create something based on this using the Bridge pattern:



Below is the UML diagram of the Bridge, which clearly shows that the client does not want to know the details of the implementation, and that the object’s abstraction is separated from the implementation.



And now an example in the form of a code:

Of course, the abstraction is the Bridge class, using dependency injection we inject into the constructor of the BridgeImplementation class, which inherits from the Bridge class the object of the class we want to operate on and we call its methods in the client.


A practical example of life taken

In order to better understand the separation of the implementation from the object’s abstraction, I will use a picture that I found somewhere in the network that illustrates well the operation of the bridge, that is separating the implementation from the interface.

The abstraction is the Class of the Bridge, which illustrates what the button is supposed to do eg on the TV, the TV, radio or lamp object is already an implementation.

I will give an example from the picture, only we will move it to the code.

The bridge is here the abstract class Switch, implementation is the TV, Radio, Lamp classes.

The case looks similar to the previous example, to the class ClickSwitch, which inherits from the Switch class, we pass the class object to the constructor using dependency injection and call the On and Off methods.



Relations with other design patterns

The Bridge pattern is quite similar to a facade or adapter. However, the facade differs mainly in that it simply has to provide a simple interface to the client, and the adapter has to combine non-matching interfaces, with smaller projects the implementation of these patterns does not differ much, however, in larger projects there are big differences.



That’s all about Bridge 🙂.

Link to github with the whole code from this article:

This content also you can find on my steemit blog

And on medium:

In the next article, we will talk about the Proxy pattern.

As a standard, I remind you about the newsletter, which I send notifications about new entries and additional information about the IT world in general.🙂

And NECESSERILY join the DevmanCommunity community on fb, part of the community is in one place 🙂

– site on fb:ławomir Kowalski

– group on fb: DevmanCommunity

Ask, comment underneath at the end of the post, share it, rate it, whatever you want🙂.

Take care 🙂

If that post was useful for you share it with your friends :)

Post a comment

Notify about