.NET 1.1+

Bridge Design Pattern

The bridge pattern is a design pattern that separates the abstract elements of a class from its technical implementation. This provides a cleaner implementation of real-world objects and allows the implementation details to be changed easily.

What is the Bridge Pattern?

The bridge pattern is a Gang of Four design pattern. This is a structural pattern as it defines a manner for creating relationships between classes or entities. The bridge pattern is used to separate the abstract elements of a class from the implementation details. For example, the abstract elements may be the business logic of an application. They can be created without any knowledge of the implementation details of their data access or interoperability with the operating system. The pattern provides the means to replace the implementation details without modifying the abstraction. This permits, for example, changing operating systems, databases, etc. with no impact to the business logic.

When the bridge pattern is not used, you may find that implementation details are included within the abstraction. In this case, the way in which implementation details are changed is probably through inheritance, with subclasses providing different implementations. This can be problematic when refined abstractions are included, also through inheritance. The number of required classes can grow exponentially as new abstractions and implementations are added to a system. In this model, when there is a single implementation for a single abstraction, only one class is required whereas the bridge pattern would involve three classes. However, if there were four abstractions and five implementations, this would potentially require twenty classes versus the ten needed when using the bridge pattern. This is due to the pattern removing platform dependencies from the abstraction.

Another benefit of the bridge pattern is that it introduces the possibility of changing the implementation details at run-time. This could permit the user to switch implementations to determine how the software interoperates with other systems. For example, allowing the user to decide whether to store information in a database, XML file or using another storage mechanism.

An example of the bridge pattern could be used within a system that sends messages, perhaps describing system status changes, warnings and errors. An abstraction class that represents a message could include properties to hold the details of the message. Several implementations could then be included to permit sending the messages via email, over a messaging queue or to a web service. The implementation to be used could then be selected according to the availability of these resources.