Bridge Design Pattern Using C#

The total reaches 9 and this will keep on increasing, as the number of methods to implement the logical code continues increasing. Further if more ways to send user notifications are added then they will add more classes to the system and it will become difficult to maintain the code and make changes in the future.

This is where the Bridge Pattern is useful and provides multiple ways to complete a task that has multiple implementations. This is what we meant by many-to-many mappings at the start of the explanation. So let's explain how to avoid this situation using this pattern.

To solve this problem, we introduce another level of abstraction. This time, it's not for the logic implementation, but for the various ways in which we can call this logic. So we create an abstract bridge that will be used to link the two systems, in other words various ways to send various types of user notifications.

Our system code will be divided into the following 4 components:

1. Abstraction
   
   This will be the abstract class that will have the abstract logic to be implemented. Most importantly, this will hold a reference to the bridge (that will internally have a reference to the system through which notification is to be sent). The rest is just like any other interface-based definition of the functions to be implemented.
   
2. Abstraction Details
   
   These will be concrete implementations of the abstraction of Step 1.
   
3. Bridge Abstraction
   
   This is the abstract component that will act as a bridge between the two components.
   
4. Bridge Implementations
   
   These are the implementations for the bridge and will provide various ways in which we can call the required logic implementations of Step 2.

So our first step will be to define the the bridge abstraction and the logic abstraction classes. Our logic abstraction class will have a reference to the abstract bridge. Next, we will implement the abstract logic and call the bridge method, using its reference, that these concrete logic based classes hold withing them. See the code below:



Next we will be have multiple implementations of the bridge, that is nothing but different ways in which we can send these user notifications. So this is nothing but another implementation of the interface, but this time its the Bridge interface.



Finally we will write the client code.



So run the code and see the results.

How it works

Now let's see what actually is happening. We are setting the basic properties of our class SendData, like we would do for any other class. One of these properties is the abstract bridge reference in the form of a property named _iBridgeComponents. So this property is basically assigned the actual or the concrete bridge that we want to use for the logic processing. In first case, its the web service and in the second case its the third-party API. So when we invoke the Send() function using this property, it is actually invoking the Send() function of the class for which it holds the reference. In the first case this happens to be the web service and in the second case, its the third-party API.
At the beginning of this article, we explained how the number of classes can increase without this pattern. Here we have 6 classes (including the interface). Even if we add another method using a WCFService, we will have only one more class added to the system, that makes it 7. So in the future, even if we keep adding the logic implementations and the methods to do it, the number of classes does not increases, as it would have without this pattern. Hope this makes it clear.

So this was all about the Bridge Design Pattern.