Introducing the Bridge Pattern

According to the Gang of Four, the intent of the Bridge pattern is to “De-couple an abstraction from its implementation so that the two can vary independently.”^[1]

^[1] Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented Software, Reading, Mass.: Addison-Wesley, 1995, p. 151.

I remember exactly what my first thoughts were when I read this:

Huh?

And then,

How come I understand every word in this sentence but I have no idea what it means?!

I knew that

• De-couple means to have things behave independently from each other or at least explicitly state what the relationship is, and

• Abstraction is how different things are related to each other conceptually.

And I thought that implementations were the way to build the abstractions; but I was confused about how I was supposed to separate abstractions from the specific ways that implemented them.

It turns out that much of my confusion was due to misunderstanding what implementations meant. Implementations here means the objects that the abstract class and its derivations use to implement themselves with (not the derivations of the abstract class, which are called concrete classes). But to be honest, even if I had understood it properly, I am not sure how much it would have helped. The concept expressed in this sentence is just hard to understand at first.

If you are also confused about the Bridge pattern at this point, that is okay. If you understand the stated intent, then you are that much ahead.

The Bridge pattern is one of the toughest patterns to understand in part because it is so powerful and applies to so many situations. Also, it goes against a common tendency to handle special cases with inheritance. However, it is also an excellent example of following two of the mandates of the design pattern community: “find what varies and encapsulate it” and “favor object composition over class inheritance” (as you will see).