The bridge design pattern can be used to decouple an abstraction from its implementation so that both can be changed independent of each other Credit: Thinkstock Design patterns are proven solutions to recurring problems and complexities that evolve in software designs. According to the Gang of Four (popularly known as GOF), there are three categories of design patterns. These include: creational, structural and behavioral. The Structural patterns are used to realize the relationships between entities. The bridge design pattern falls under the structural design pattern category. A good example of a Structural design pattern is the Adapter pattern. We explored this pattern in an earlier article here. This article discusses the bridge design pattern with code examples to illustrate the concepts covered. Why do we need the bridge design pattern anyway? You can take advantage of the bridge design pattern to provide an alternative to inheritance. In essence, the bridge design pattern provides a way to isolate abstraction from its implementation so that both can be modified independent of each other. Although the Adapter and bridge design patterns are related but there are distinct differences between them. While the former is used to map incompatible or unrelated interfaces, the latter is used to provide an abstract interface for an implementation that can vary over time. The advantage of the bridge design pattern is that the abstraction and its implementation are decoupled. The best part is that the implementation can be changed dynamically at run time. In other words, this design pattern enables you to implement a design in which the abstraction and implementation are decoupled from each other and both can vary independently. You can take advantage of the bridge design pattern when your design needs the abstractions and implementations to be able to vary independent of each other and also when the changes in the implementation would not have any impact on the consumers. Implementing the bridge design pattern The bridge design pattern is an implementation of the famous design choice “prefer composition over inheritance”. The four major participants in this design pattern include the following: Abstraction: this is represented by an abstract class Redefined abstraction: this is represented by a class that extends the abstract class Bridge: this is represented by an interface that acts as a bridge between the abstract class and the implementation class Implementation: this is represented by a class that implements the bridge interface and provide concrete implementation for the abstract class Let’s get into some coding now. Refer to the INotification interface given below. public interface INotification { void Notify(string message); } As you can see in the above code snippet, the INotification interface contains the method declaration of just one method named, Notify. The Notify method accepts a string message as an argument and returns void. The abstract class Notification contains a property of type INotification and also contains an abstract method named Notify. The following code snippet illustrates how the abstract class Notification looks like. public abstract class Notification { public INotification NotificationComponent { get;set; } public abstract void Notify(string message); } The DBNotification and EmailNotification concrete classes extend the abstract base class Notification and defines the Notify method in them. The following code snippet shows how these two classes are represented. Note that both these classes contain the method definition of the Notify method. The Notify method is declared as an abstract method in the abstract base class named Notification. public class DBNotification : Notification { INotification notify; public override void Notify(string message) { notify = base.NotificationComponent; notify.Notify(message); } } public class EmailNotification : Notification { INotification notify; public override void Notify(string message) { notify = base.NotificationComponent; notify.Notify(message); } } The following two classes represent two different implementations of the bridge. Note that both these classes implement the INotification interface. public class DBManager : INotification { public void Notify(string message) { Console.WriteLine(message); } } public class LoggingManager : INotification { public void Notify(string message) { Console.WriteLine(message); } } The following code listing shows how you can invoke the Notification library we just implemented from the Main method. class Program { static void Main(string[] args) { Notification obj = new DBNotification(); obj.NotificationComponent = new DBManager(); obj.Notify("DBNotification"); Console.Read(); } } You can learn more on this design pattern here. Related content feature 14 great preprocessors for developers who love to code Sometimes it seems like the rules of programming are designed to make coding a chore. Here are 14 ways preprocessors can help make software development fun again. By Peter Wayner Nov 18, 2024 10 mins Development Tools Software Development feature Designing the APIs that accidentally power businesses Well-designed APIs, even those often-neglected internal APIs, make developers more productive and businesses more agile. By Jean Yang Nov 18, 2024 6 mins APIs Software Development news Spin 3.0 supports polyglot development using Wasm components Fermyon’s open source framework for building server-side WebAssembly apps allows developers to compose apps from components created with different languages. By Paul Krill Nov 18, 2024 2 mins Microservices Serverless Computing Development Libraries and Frameworks news Go language evolving for future hardware, AI workloads The Go team is working to adapt Go to large multicore systems, the latest hardware instructions, and the needs of developers of large-scale AI systems. By Paul Krill Nov 15, 2024 3 mins Google Go Generative AI Programming Languages Resources Videos