Outline
In the software system, certain types due to its own logic, which has two or more dimensions of change, how to deal with this "multi-dimensional change"? How to use object-oriented technology to make this type can easily be varied along the plurality of directions, without introducing additional complexity? It is necessary to use Bridge mode.
Bridge mode is a very useful model, but also a more complex pattern. This mode familiar to understand object-oriented design principles, including "on - off" Principles (OCP), and combinations / polymerization multiplexing principles (the CARP) are very helpful. Good understanding of these two principles to help form the correct design and develop good design.
intention
Abstract achieve partial separation portion, so that they can vary independently. [GOF "Design Mode"] abstract and implement the concept here is not necessarily the same level, such as database operations can be attributed to "add, delete and modify." Many business processes are achieved through the operation of the database, such as "inventory management" in the "storage", the business software implementation of the action can be described as "a record increase in the inventory table" and "storage" and "insert record" at different business levels.
<Design Pattern> FIG structure
1 Bridge pattern configuration diagram of FIG.
As can be seen, this system comprises two hierarchical structure, namely:
- Abstract abstraction hierarchy of roles and role corrected abstract composition.
- Realization of the role and the role of the two to achieve the specific implementation consisting of hierarchy.
Bridge role models involved are:
- Abstraction (Abstraction) Role: abstract definitions given, and save a reference to the realization of the object.
- Correction abstraction (Refined Abstraction) Role: Extended abstract roles change and amend the definition of the parent class abstract.
- Realization of (Implementor) Role: This role gives the realization of the role of the interface, but does not give a specific implementation. It must be noted that this interface is not necessarily the same abstract interface defines the role, in fact, these two interfaces can be very different. It should be given only to achieve the role of the underlying operating, and abstract character should be given a higher level of operating only on the underlying operations.
- Concrete realization of (Concrete Implementor) Role: This role gives the realization of concrete realization of the role of the interface.
Life examples
Abstract bridge mode portion and its separation, so that they can vary independently. A common switch-controlled lights, fans, etc., are examples of bridging. Purpose is to switch the device on or off. The actual pole switch may be a simple pull chain switch, a dimmer switch may be.
FIG 2 using the example of the electronic switch bridges FIG objects
Metaphor
We have a child with crayons, a box of crayons 12 colors. I always start with the sun would draw a minimum number of crayons, moon mother enough. Later began to draw some abstract works, you have to change the number, or else draw a background to be described for a long time, a good number in a box of 12 colors also. And then I turned to Unconstrained, the number a bit stretched, and had to change the large, well the only large box of 12 colors. You see, like me, a little-known artist will need 36 kinds of brush, wow, too much trouble. But according to my observation, other than my famous painter did not make so many pens, they only have a few brushes and some of the paint, this would resolve the "kind of explosion" of the crayon. As shown below:
I use 36 kinds of crayons 
Qi old man only three kinds of pigment and 12 brush
Exemplary embodiment using FIG.
A control program on and off, and what type of control, such as: TV, lights, and so fits bridging mode, use cases is as follows:
Code design
Create CntrlControl.cs:
/// <summary>
/// control class
/// </summary>
public abstract class CntrlControl
{
/// <summary>
/// turn on
/// </summary>
/// <returns></returns>
public abstract string TurnOn();
/// <summary>
/// turn off
/// </summary>
/// <returns></returns>
public abstract string TurnOff();
}
Then create Lamp.cs:
public class Lamp:CntrlControl
{
public override string TurnOn()
{
return "灯亮了";
}
public override string TurnOff()
{
return "灯关了";
}
}
Then create Television.cs:
public class Television:CntrlControl
{
public override string TurnOn()
{
return "电视开了";
}
public override string TurnOff()
{
return "电视关了";
}
}
Then create ControlCenter.cs:
/// <summary>
/// control center
/// </summary>
public abstract class ControlCenter
{
private CntrlControl centerControl;
public CntrlControl CenterControl
{
get
{
return centerControl;
}
set
{
centerControl = value;
}
}
public ControlCenter()
{ }
public ControlCenter(CntrlControl cntrlControl)
{
this.centerControl = cntrlControl;
}
public abstract string TurnOn();
public abstract string TurnOff();
}
Then create LampControl.cs:
public class LampControl:ControlCenter
{
public override string TurnOn()
{
return "我房间的灯控制"+ CenterControl.TurnOn();
}
public override string TurnOff()
{
return "我房间的灯控制" + CenterControl.TurnOff();
}
public LampControl()
{ }
public LampControl(CntrlControl cntrlControl)
: base(cntrlControl)
{ }
}Then create TVControl.cs:
public class TVControl:ControlCenter
{
public override string TurnOn()
{
return "客厅的电视控制"+ CenterControl.TurnOn();
}
public override string TurnOff()
{
return "客厅的电视控制" + CenterControl.TurnOff();
}
public TVControl()
{ }
public TVControl(CntrlControl cntrlControl)
: base(cntrlControl)
{ }
}Finally, call:
public partial class Run : Form
{
public Run()
{
InitializeComponent();
}
private void btnRun_Click(object sender, EventArgs e)
{
//-------------------------------------
ControlCenter lampControl = new LampControl(new Lamp());
rtbResult.AppendText("节能灯控制开始.\n");
rtbResult.AppendText(lampControl.TurnOn() + "\n");
rtbResult.AppendText(lampControl.TurnOff() + "\n");
rtbResult.AppendText("节能灯控制结束.\n\n\n");
ControlCenter tvControl = new TVControl(new Television());
rtbResult.AppendText("电视控制开始.\n");
rtbResult.AppendText(tvControl.TurnOn() + "\n");
rtbResult.AppendText(tvControl.TurnOff() + "\n");
rtbResult.AppendText("电视控制结束.\n");
//-------------------------------------
}
}
FIG results are as follows:
Effects and achieve points
1. Bridge mode using the "combination relationships between objects" decoupling inherent binding between the abstract and the implementation and realization of such an abstract may vary along the respective dimension.
2. The so-called abstract and implement changes along each dimension, namely "subclass" They give the various sub-categories, they will be able to arbitrarily to obtain different models on different platforms.
3. Bridge mode is similar to multiple inheritance scheme sometimes, but often multiple inheritance scheme violates the Single Responsibility Principle class (ie a class has only one reason for the change), poor reusability. Bridge mode is better than multiple inheritance scheme solution.
4. Bridge mode application generally "two very strong dimensions of change", even if sometimes there are two dimensions of change, but change is not dramatic dimension in a certain direction - in other words two changes do not lead to results criss-cross, You do not have to use Bridge mode.
5. Select the appropriate type of role as an abstraction (first dimension).
6. Abstract realization of the role and the role of associate by combining.
7. Abstract and realize not binding, allowing the client to make switching.
applicability
Bridge mode should be used in the following cases:
1. If a system needs to add more flexibility between abstract and concrete role members of the role, to avoid static build links between the two levels.
2. Design requirements to achieve any change should not affect the role of the client, or to change the implementation of the role of the client is completely transparent.
3. A member of more than one role and implementation of the abstract character, the system needs to be dynamically coupled therebetween.
4. Although the use of inheritance in the system is no problem, but because of the role of abstract and concrete role needs to change independently, the design requirements need to independently manage both.
5. From the perspective of the code, if the type of inheritance in object 2 (single violation of the principle of duty), then patterns can be used to avoid excessive Bridge subclass.
6. Time, if the application will vary from application point of view in multiple dimensions, the client wants the object in two dimensions (the scene, the game mode) is relatively independent, dynamic coupling (which scene mode coupling and which game client decides) the Bridge mode can be considered.
to sum up
Bridge mode is a useful mode, is also very complex, it fit well with the open - closed principle and priority use of objects, instead of inheriting both object-oriented principles.
Reproduced in: https: //www.cnblogs.com/springyangwc/archive/2011/04/20/2023030.html