Chapter 21: The Bridge Pattern

In the previous two chapters, we covered our first structural pattern, adapter, which is used to make two incompatible interfaces compatible, and decorator, which allows us to add responsibilities to an object in a dynamic way. There are more similar patterns. Let's continue with the series!

A third structural pattern to look at is the bridge pattern. We can actually compare the bridge and the adapter patterns by looking at the way they work. While the adapter is used to make unrelated classes work together (as we saw in the implementation example discussed in Chapter 19, The Adapter Pattern), the bridge pattern is designed upfront to decouple an implementation from its abstraction, as we are going to see in this chapter.

Specifically, we will discuss the following topics:

• Real-world examples
• Use cases
• Implementation

By the end of this chapter, we will know how to implement this design pattern and understand better the...

Technical requirements

The code files for this chapter can be accessed through this link: https://github.com/PacktPublishing/Advanced-Python-Programming-Second-Edition/tree/main/Chapter21.

Real-world examples

In our modern, everyday lives, one example of the bridge pattern that I can think of is information products from the digital economy. Nowadays, the information product, or infoproduct is part of the resources you can find online for training, self-improvement, or your ideas and business development. The purpose of an information product found on certain marketplaces, or the website of the provider, is to deliver information on a given topic in such a way that it is easy to access and consume. The material provided can be a PDF document or ebook, an ebook series, a video, a video series, an online course, a subscription-based newsletter, or a combination of all those formats.

In the software realm, device drivers are often cited as an example of the bridge pattern, when the developer of an operating system (OS) defines the interface for device vendors to implement it.

Next, let's discuss when this design pattern should be employed.

Use cases

Using the bridge pattern is a good idea when you want to share an implementation among multiple objects. Basically, instead of implementing several specialized classes, defining all that is required within each class, you can define the following special components:

• An abstraction that applies to all the classes
• A separate interface for the different objects involved

Next, we will see an implementation example that illustrates this approach.

Implementation

Let's assume we are building an application where the user is going to manage and deliver content after fetching it from diverse sources, which could be the following:

• A web page (based on its URL)
• A resource accessed on an FTP server
• A file on the local filesystem
• A database server

So, here is the idea: instead of implementing several content classes, each holding the methods responsible for getting the content pieces, assembling them, and showing them inside the application, we can define an abstraction for the Resource Content and a separate interface for the objects that are responsible for fetching the content. Let's try it!

We begin with the class for our Resource Content abstraction, called ResourceContent. Then, we will need to define the interface for implementation classes that help fetch content, that is, the ResourceContentFetcher class. This concept is called the Implementor.

The first trick we use here is to use...

Summary

In this chapter, we discussed the bridge pattern. Sharing similarities with the adapter pattern, the bridge pattern differs in the sense that it is used upfront to define an abstraction and its implementation in a decoupled way so that both can vary independently.

The bridge pattern is useful when writing software for problem domains such as OSs, device drivers, GUIs, and website builders where we have multiple themes, and we need to change the theme of a website based on certain properties.

To help you understand this pattern, we discussed an example in the domain of content extraction and management, where we defined an interface for the abstraction, an interface for the Implementor, and two implementations.

In the next chapter, we are going to cover the façade pattern.

Questions

1. What is the main motivation for the bridge pattern?
2. How does the bridge pattern differ from the adapter pattern?
3. How is the bridge pattern implemented in the Python example of content extraction we considered?