for example
If we need to develop a support both PC and mobile phone side of the tank game, game on the PC and mobile phone functions are the same, have the same type, face the same demand function changes, such as tanks, there could be many different models: T50, T75 , T90 ......
For tank design them, we could easily design a Tank out of the abstract base class, and then a variety of different types of Tank inherited from class;
This step is achieved no problem, also in line with the principle of opening and closing, read on.
Additional reasons for the changes
But the graphics rendering on the PC and mobile phone, sound effects, and other operations to achieve a completely different ...... so for various types of tanks, the tanks must be provided on a variety of different platforms to achieve:
We usually designed in such a way, but this weird look, this design will bring a lot of problems: There are a lot of duplicate code, the class structure is too complex, difficult to maintain, the most deadly is the introduction of any new platforms, such as on the TV Tank game, and make the entire class hierarchy complicated. We do software, modified, modify the better, indicating that isolation is better.
Motivation (Motivation)
The crux of the problems described above thinking: in fact due to the inherent logic Tank type, making Tank type has the two dimensions of change - a change of dimension "platform of change," a change of dimension "change models."
How to deal with this "multi-dimensional change"? How to use object-oriented technology to make Tank type can easily change both directions along the "platform" and "model", without introducing additional complexity?
Intent (Intent)
Abstract achieve partial separation portion, so that they can be independently varied.
Structure (Structure)
Which imp place is a combination. Abstraction is our example Tank, which is a subclass of RefinedAbstraction T50 models. Implementor is TankPlatformImplementation classes, ConcreteImplementorA and ConcreteImplementorB are PCTankImplementation and MobileTankImplementation.
Key to the whole design pattern is to use combinations.
application
public abstract class TankModel { protected TankPlatformImplementation _tankImp; public TankModel(TankPlatformImplementation tankImp) { _tankImp = tankImp; } public abstract void Run(); } public abstract class TankPlatformImplementation { public abstract void MoveTankTo(int x, int y); public abstract void DrawTank(); public abstract voidAttack (); } /// <Summary> /// the PC tank /// </ Summary> public class PCTankImplatation: TankPlatformImplementation { String _tankModel; public PCTankImplatation ( String tankModel) { _tankModel = tankModel; } /// <Summary> /// draw tanks /// </ the Summary> public the override void DrawTank () { Console.WriteLine (_tankModel + " PC tank draw success! "); } /// <Summary> /// tank moving /// </ Summary> /// <param name = "X"> X-coordinate </ param> /// <param name = "Y"> Y coordinate </ param> public the override void MoveTankTo ( int X, int Y) { Console.WriteLine (_tankModel + " the PC tank has been moved to the coordinate ( " + X + " , " + Y + " ) at " ); } // / <Summary> /// attack /// </ Summary> public the override void Attack () { Console.WriteLine (_tankModel + " the PC tank began to attack " ); } } /// <Summary> /// T50 Model tank /// </ Summary> public class T50: TankModel { public T50 (TankPlatformImplementation tankImp): Base (tankImp) {} public the override void the Run () { _tankImp.DrawTank (); _tankImp.MoveTankTo ( 100 , 100 ); _tankImp.Attack(); } } /// <summary> /// 客户端调用 /// </summary> public class App { void Main(string[] agrs) { T50 t = new T50(new PCTankImplatation("T50")); t.Run(); } }
After using the bridge mode, when requirements change it is easy to deal with, and if now the addition of a model T60 tanks, and added a mobile platform. T60 models only need to add specific classes and concrete classes to mobile platforms, as follows:
/// <Summary> /// Mobile tanks /// </ Summary> public class MobileTankImplatation: TankPlatformImplementation { String _tankModel; public MobileTankImplatation ( String tankModel) { _tankModel = tankModel; } /// <Summary> /// drawing tank /// </ Summary> public the override void DrawTank () { Console.WriteLine (_tankModel + " Mobile drawing tank success! " ); } /// <Summary> /// tank moving /// </ Summary> /// <param name = "X"> X-coordinate </ param> /// <param name = "Y"> Y-coordinate </ param> public the override void MoveTankTo ( int X, int Y) { Console.WriteLine (_tankModel + " mobile tank has been moved to the coordinate ( " + X + " , " + Y + " ) at " ); } /// <Summary > /// attack /// </ the Summary> public the override void Attack () { Console.WriteLine (_tankModel + " Mobile tank began to attack " ); } } /// <Summary> /// T60 Model tank /// </ Summary> public class T60: TankModel { public T60 ( tankImp TankPlatformImplementation): Base (tankImp) {} public the override void the Run () { _tankImp.DrawTank (); _tankImp.MoveTankTo ( 400 , 100 ); _tankImp.Attack (); } }
After adding these two classes now we have models T50, T60 models, PC platforms, mobile platforms, though only added two classes, but now have four combinations, see the calling client code:
/// <Summary> /// client calls /// </ Summary> public class the App { void the Main ( String [] as AGRS) { // T50 on the PC T50 = t50PC new new T50 ( new new PCTankImplatation ( " T50 " )); t50PC.Run (); // T50 on Mobile T50 t50Mobile = new new T50 ( new new MobileTankImplatation ( " T50 " )); t50Mobile.Run (); // T60 on PC T60 t60PC =new T60(new PCTankImplatation("T60")); t60PC.Run(); //T60在Mobile上 T60 t60Mobile = new T60(new MobileTankImplatation("T60")); t60Mobile.Run(); } }
Bridge mode of several key points
Bridge mode using the "combination relationships between objects" decoupling inherent binding between the abstract and the implement, such that the abstract (Tank models) and implement (different platforms) may vary along the respective dimension.
Called abstract and implement changes along each dimension, i.e., "subclassing" thereof (such as different models of Tank subclasses, subclasses and different platforms), to give after each subclass can any combination thereof, thereby obtaining different different models on the platform.
Sometimes Bridge mode is similar to multiple inheritance scheme, but multiple inheritance scheme is often contrary to the principle of single responsibility (ie only one reason for a class change), poor reusability. Bridge mode is better than multiple inheritance scheme solution.
The following is a way to write for the above example, the interface of multiple inheritance:
Such PCT50 only need to write achieve T50, but also to write achieve Platform, which is to change the model and platforms have introduced PCT50. This put the two together should not twist the affairs of twisted together, this design is even worse, but also violated the principle of single responsibility class.
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.
Bridge mode and the adapter is different from the mode, the adapter mode is actually a wise after the event, when previously found what measures do not apply only to do a make up. Bridge mode changes made relatively earlier than the adapter mode, it can be applied to change two or even more than two dimensions.