Bridging mode of design mode

Design patterns are not based on theoretical inventions. Instead, there is always a problem scenario, and then evolve the design based on requirements and scenarios, and finally standardize some of the scenarios into "patterns." Therefore, when we discuss each design pattern, we should try to use real problems in life to understand and analyze. Then try to step through the design and end up with a design that matches certain patterns.

Design Problems and Solutions

First let's consider the following scenario:
Our homes have household appliances (such as lights and fans) that are controlled by switches. At any time, you can do something without changing anything else. You can replace the lamp without changing the switch, or you can change the switch without touching the bulb or the fan, or even swap the lamp and fan switch without touching the switch.

Bulbs and fans

Different types of switches

When different things are linked together, they should be in a system that can be changed or can be replaced so as not to affect each other, or as small as possible. This makes it easier and more cost-effective to manage your system. Can you imagine that if you were to change a light bulb in your room and have to change the switch, would you consider using a system like this in your house? Of course not. Now, let's think about how the lights or electric fans are connected to the switch to replace one without affecting the other. Of course it's a wire. It is wire and other electrical means to connect the lamp/electric fan to the switch. We can generalize this as a bridge between different systems. The basic idea is that one thing cannot connect directly to another. Of course, they can be connected by some bridge or interface. In the software world, we call it "loose coupling."
Now, let's try to understand some of the key issues similar to electric light/electric fans and switches, while trying to understand how to design and correlate them.
In our case, there are some switches, these are similar to ordinary switches, there are different fancy switches may have different kinds, but, in general, they are switches. At the same time, each switch can be turned on and off.
In this case, we will get the following switch base class:

1 public class switch 2 {3 publicly     void on () 4     {5        //switch has a "on" button 6     } 7  public     void Off () 8     { 9         //switch has a "off" button     }11}

At the same time, we may also need some specific types of switches, such as normal switches, different fancy switches and so on. Likewise we extend the switch class to implement Fancyswitch and Normalswitch:

1 public class Normalswitch:switch2 {3}4 5 public class Fancyswitch:switch6 {7}

These two specific switch classes may be used for their own unique behavior and characteristics, but so far we have kept their simple form.

Now, how do you handle fans and lights?
In accordance with the principles of object-oriented design, I think we need to try to do abstract processing wherever possible.
Fans and electric lights are a little different, they are two not the same thing. For different switches, we can use the same basic switch class, but it is not suitable for fans and electric lights, it feels more appropriate to use the interface. Because, in general, they are all electrical appliances, then we can define an interface: Ielectricalequipment, which is used to abstract fans and electric lights.
So, all appliances have some commonality that can be turned on and off. Then this interface can be:

1 public interface IElectricalEquipment2 {3     void PowerOn ();//Each appliance can be opened 4     void PowerOff ();//each appliance can be closed 5}

Well, now we're missing a bridge. In the real world, a bridge is a wire. In the world of objects, switches know how to switch appliances, and electrical appliances need to be connected to the switch in some way. But there are no wires here, the only thing we have, is encapsulation.

The switch does not know the presence of electric fans and lights. It only knows that it can turn on or off an electrical ielectricalequipment. So, that means each switch should have a ielectricalequipment instance.
Here, the encapsulated instance, Ielectricalequipment, is the bridge. OK, let's change the switch class so that it wraps the appliance in:

1 public class Switch 2 {3 publicly     ielectricalequipment equipment 4     {5         get; 6         set; 7     } 8 public     V OID on () 9     {Ten         //switch has an open button all     }12 public     Void Off ()          a button that has a close on ()//switch (     }16}

Then I'll define the real appliance. Electric fans and electric lights are generally electrical, so they should implement the Ielectricalequipment interface.

Fan Type:

1 public class Fan:ielectricalequipment 2 {3 public     void PowerOn () 4     {5           Console.WriteLine ("Fan was on") 6< c3/>} 7 public     void PowerOff () 8     {9          Console.WriteLine ("Fan is Off");     }11}

Lamp Type:

1 public class Light:ielectricalequipment 2 {3 publicly      void PowerOn () 4     {5          Console.WriteLine ("Light is O n "); 6     } 7 public     void PowerOff () 8     {9         Console.WriteLine ("Light is Off");     }11}

Very good. Now it's time to pick up the switch. When the switch is on and off, it must be able to open and close the appliance it is connected to.

Other words:
• When you press the Open button on the switch, the connected appliance must be turned on.
• When the switch's off button is pressed, the connected appliance must be turned off.
The function we want is basically like this:

1 static void Main (string[] args) 2 {3     ///We have some appliances, such as fans, lights, etc., so we'll first create them 4     ielectricalequipment fan = new Fan (); 5
   ielectricalequipment light = new Light ();  6     //We also have some switches that also need to create them 7     switch fancyswitch = new Fancyswitch (); 8     Switch normalswitch = new Normalswitch (); 9     Let's connect the electric fan and the electric fan switch     one at a time fancyswitch.equipment = fan;12//The switch now corresponds to a device (fan), so it can switch the device.     ///below this operation will open the fan///     of course, in this on () method of the switch we must turn on the appliance.     Fancyswitch.on (); +/     /below this operation will turn off the fan     Fancyswitch.off ();     //Now we connect     the light to the fan switch. Fancyswitch.equipment = light;22     fancyswitch.on ();//Now it will turn on the lamp     Fancyswitch.off ();//Now it will turn off the lamp 24}

Then the on () method of the switch should call the appliance's Turnon () method, and its off () method should call the appliance's turnoff () method, and the switch class should look like this:

1 public class Switch 2 {3 publicly     void on () 4     {5         Console.WriteLine ("Switch on the equipment"); 6         Equipme Nt. PowerOn (); 7     } 8 public     void Off () 9     {         Console.WriteLine ("Switch Off the Equipment");         equipment. PowerOff ();     }13}

The fan shows that the switch can be switched on. And, in turn, can be changed, can not modify the electric fans and lights, directly replace the switch, for example, we can change the light switch from Fancyswitch to Normalswitch:

1 normalswitch.equipment = Light;2 Normalswitch.on (); It should turn on the light now3 Normalswitch.off (); It should be turn off

See, we can change the other party without affecting either party. The design looks pretty good, and it's pretty classy. In fact Gang of four (GoF) tube This design called bridging mode.

In general, two systems should not be directly connected and dependent on each other. Instead, they should be joined or relied upon by abstraction (see dependency inversion and opening and closing principles) so they are loosely coupled, and we can easily modify the implementation if necessary without too much impact on the rest of the system.

Definition of bridging mode

Let's look at the definition of bridging mode:

　　　　"Decoupling abstractions and implementations so that they can vary independently"

The class diagram structure of the bridging mode is as follows:

In our case, abstraction is the basic switch class, refinedabstraction is a specific switch class (Fancyswitch and Normalswitch), Implementor is the Ielectricalequipment interface, Concreteimplementora and Concreteimplementorb are fan and light classes respectively.
Bridging mode is the basis for all object-oriented design patterns. Because:
• It teaches you how to think abstractly, which is the key to OO design patterns.
• It implements the basic Ood principle.
• It is well understood.
• Learning other patterns is easy if you can understand them correctly.

Bridging mode of design mode