The Bridge Pattern

6 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, looking at the way both work. While adapter is used later to make unrelated classes work together, as we saw in the implementation example we discussed in Chapter 4, *The Adapter Pattern, the bridge pattern is designed up-front to decouple an implementation from its abstraction, as we are going to see.

In this chapter, we will discuss:

• Real-world examples
  • Use cases
    • Implementation

Real-world examples

In our modern, everyday lives, an example of the bridge pattern I can think of is from the digital economy: information products. Nowadays, the information product or infoproduct is part of the resources one can find online for training, self-improvement, or one's ideas and business development. The purpose of an information product that you find 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 provided material 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.

The Bridge Pattern Chapter 68*

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

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

An implementation example we are about to see will illustrate 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:

• A web page (based on its URL)
  • A resource accessed on an FTP server
    • A file on the local file system
      • 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 that, via an attribute (_imp) on the ResourceContent class, we maintain a reference to the object which represents the Implementor:

class ResourceContent:

"""

Define the abstraction's interface.

Maintain a reference to an object which represents the Implementor. """

def __init__(self, imp): self._imp = imp

def show_content(self, path): self._imp.fetch(path)

As you may know now, we define the equivalent of an interface in Python using two features of the language, the metaclass feature (which helps define the type of a type), and abstract base classes (ABC):

class ResourceContentFetcher(metaclass=abc.ABCMeta):

"""

Define the interface for implementation classes that fetch content. """

@abc.abstractmethod

def fetch(path):

pass

Now, we can add an implementation class to fetch content from a web page or resource:

class URLFetcher(ResourceContentFetcher):

"""

Implement the Implementor interface and define its concrete implementation.

"""

def fetch(self, path):

• path is an URL

req = urllib.request.Request(path)

with urllib.request.urlopen(req) as response:

if response.code == 200:

the_page = response.read() print(the_page)

We can also add an implementation class to fetch content from a file on the local filesystem:

class LocalFileFetcher(ResourceContentFetcher):

"""

Implement the Implementor interface and define its concrete implementation.

"""

def fetch(self, path):

• path is the filepath to a text file

with open(path) as f: print(r.read())

Based on that, our main function to show content using both content fetchers could look like the following:

def main():

url_fetcher = URLFetcher()

iface = ResourceContent(url_fetcher) iface.show_content('http://python.org')

print('===================')

localfs_fetcher = LocalFileFetcher()

iface = ResourceContent(localfs_fetcher) iface.show_content('file.txt')

Let's see a summary for the complete code of our example (the bridge.py file):

1. We import the three modules we need for the program (abc, urllib.parse, and urllib.request).
2. We define the ResourceContent class for the interface of the abstraction.
3. We define the ResourceContentFetcher class for the Implementator.
4. We define two implementation classes:

• URLFetcher for fetching content from an URL
  • LocalFileFetcher for fetching content from the local filesystem
    • Finally, we add the main() function, as shown earlier, and the usual trick to call it

Here is a sample output when executing the python bridge.py command:

This is a basic illustration of how, using the bridge pattern in your design, you can extract content from different sources and integrate the results in the same data manipulation system or user interface.

Summary

In this chapter, we discussed the bridge pattern. Sharing similarities with the adapter pattern, the bridge pattern is different from it, in the sense that it is used up-front 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 operation systems and 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.

[ 68 ] )