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 how-to How to use FastEndpoints in ASP.NET Core Take advantage of the free open-source FastEndpoints library to build fast and lean APIs in your ASP.NET Core applications. By Joydip Kanjilal Jul 11, 2024 7 mins Microsoft .NET C# Development Libraries and Frameworks how-to How to use Refit to consume APIs in ASP.NET Core Take advantage of Refit REST library to simplify API consumption and make your code cleaner, more efficient, and easier to maintain. By Joydip Kanjilal Jul 04, 2024 10 mins C# Microsoft .NET Software Deployment how-to When to use an abstract class vs. interface in C# Understanding the differences between an abstract class and interface is key to designing loosely coupled and extensible applications. By Joydip Kanjilal Jun 20, 2024 10 mins Small and Medium Business Microsoft .NET C# how-to 6 security best practices for ASP.NET Core Learn the best practices and built-in safeguards for preventing attacks and protecting sensitive data in your ASP.NET Core web applications. By Joydip Kanjilal Jun 07, 2024 6 mins C# Microsoft .NET Web Development Resources Videos