Design Mode note (8)-Bridge Mode (Structural)

Document directory

• Gof Definition
• Motivation
• Key points of the Bridge Mode

Gof Definition

Separate the abstract part from the implementation part so that they can all change independently.

Let's look at a simple example. Suppose we need to develop a tank game that supports both PC and mobile phones. The game features the same on both PC and mobile phones and has the same type, there are also changes in functional requirements, and the tanks in these games have a variety of different models: T50 t60 and so on. Based on the object-oriented thinking, we can easily design an abstract class of tank (tank), and different models inherit the abstract class, and draw images on PCs and mobile phones, operations are different, so different platforms must provide their own implementation:

Tank abstract class

/// <Summary> // The abstract class of the tank /// </Summary> public abstract class tank {public abstract void start (); public abstract void attack ();}

Different Models

/// <Summary> /// T50 model /// </Summary> public class T50: Tank {public override void attack () {} public override void start () {}}/// <summary> /// t60 model /// </Summary> public class t60: Tank {public override void attack () {} public override void start (){}}

Implementation on mobile phones

/// <Summary> /// mobilet50 model /// </Summary> public class mobilet50: t50 {// <summary> /// start /// </Summary> Public override void start () {}/// <summary> /// attack /// </Summary> Public override void attack () {}}/// <summary> /// mobilet60 model /// </Summary> public class mobilet60: tank {// <summary> /// start /// </Summary> Public override void start () {}/// <summary> /// attack /// </Summary> Public override void attack (){}}

Implementation on PC

Public class pct50: T50 {// code is similar to that in the mobile phone} public class pct60: t60 {// code is similar to that in the mobile phone}

Client call

/// <Summary> /// call the mobile client /// </Summary> public class mobileapp {void main (string [] ARGs) {tank T; T = new mobilet50 (); T. start (); T. attack (); t = new mobilet60 (); T. start (); T. attack () ;}/// <summary> // call the PC Client /// </Summary> public class pcapp {void main (string [] ARGs) {//...}}

This design has no problem when the demand is relatively stable, but this is often not the case. We can have more models such as t80, T90, and t100, in addition, the platform may not only support mobile phones and PCs, but also PSP and handheld computers. When there is such a two-way demand change, if the above design will bring a lot of problems, there will be more repeated code, and the structure between classes will become very complex, adding a new platform and several models will be troublesome. For example:

Motivation

Think about the above question: in fact, due to the inherent logic of the tank type, the tank type has two changing dimensions: "platform change" and "Model Change ". How can we cope with this "multi-dimensional change "? How can we use object-oriented technology to make the tank type change easily along the "Platform" and "model" without introducing additional complexity? This is the problem to be solved in the bridge mode.

Since there are two dimension changes involved, we need to relate these two dimensions to abstract classes, and then try to associate them to create abstract classes of "Platform" and "model" first, as follows:

/// <Summary> // abstract class of the tank model /// </Summary> public abstract class tankmodel {public abstract void run ();} /// <summary> // abstract class of the platform /// </Summary> public abstract class tankplatformimplementation {public abstract void movetankto (int x, int y ); public abstract void drawtank (); public abstract void attack ();}

Now we can associate the two classes by combining them and modify the classes of the tank model. The modified code is as follows:

/// <Summary> // abstract class of the tank model /// </Summary> public abstract class tankmodel {protected tankplatformimplementation _ tankimp; /// <summary> /// input the platform object in the constructor // </Summary> /// <Param name = "tankimp"> </param> Public tankmodel (tankplatformimplementation tankimp) {_ tankimp = tankimp;} public abstract void run ();}

The abstract class has been completed. Now, assuming there are PCs and T50 tanks, the implementation is as follows:

PC platform type

/// <Summary> // PC tank // </Summary> public class pctankimplatation: tankplatformimplementation {string _ tankmodel; Public pctankimplatation (string tankmodel) {_ tankmodel = tankmodel;} // <summary> // draw a tank // </Summary> Public override void drawtank () {console. writeline (_ tankmodel + "PC tank drawn successfully! ");} /// <Summary> // tank movement // </Summary> /// <Param name = "X"> X coordinate </param> /// <Param name = "Y"> Y coordinate </param> Public override void movetankto (int x, int y) {console. writeline (_ tankmodel + "the PC tank has been moved to the coordinates (" + x + "," + Y + ");} /// <summary> /// attack /// </Summary> Public override void attack () {console. writeline (_ tankmodel + "PC tank attack started ");}}

T50 tank type

/// <Summary> /// T50 tank model /// </Summary> public class T50: tankmodel {public T50 (tankplatformimplementation tankimp): Base (tankimp) {} public override void run () {_ tankimp. drawtank (); _ tankimp. movetankto (100,100); _ tankimp. attack ();}}

Client call

/// <Summary> // client call // </Summary> public class app {void main (string [] AGRs) {T50 T = new T50 (New pctankimplatation (); T. run ();}}

At this point, the code of the bridge mode is basically completed. It is mainly implemented by combining methods in the abstract class. The following describes the structure of the bridge mode.

After the bridge mode is used, it is easy to handle the problem when the demand changes. If there is another t60 tank and a mobile phone platform is added. You only need to add the t60 type and the mobile phone platform type, as shown below:

/// <Summary> // mobile phone tank // </Summary> public class mobiletankimplatation: tankplatformimplementation {string _ tankmodel; Public mobiletankimplatation (string tankmodel) {_ tankmodel = tankmodel;} // <summary> // draw a tank // </Summary> Public override void drawtank () {console. writeline (_ tankmodel + "mobile tank drawn successfully! ");} /// <Summary> // tank movement // </Summary> /// <Param name = "X"> X coordinate </param> /// <Param name = "Y"> Y coordinate </param> Public override void movetankto (int x, int y) {console. writeline (_ tankmodel + "mobile tank has been moved to the coordinates (" + x + "," + Y + ");} /// <summary> /// attack /// </Summary> Public override void attack () {console. writeline (_ tankmodel + "mobile tank attack") ;}/// <summary> // t60 tank model /// </Summary> public class t60: tankmodel {public t60 (tankplatformimplementation tankimp): Base (tankimp) {} public override void run () {_ tankimp. drawtank (); _ tankimp. movetankto (400,100); _ tankimp. attack ();}}

After the two classes are added, we now have t50, t60, PC, and mobile platforms. Although only two classes are added, there are now four combinations, check the client code call:

/// <Summary> // client call // </Summary> public class app {void main (string [] AGRs) {// T50 on PC T50 t50pc = new T50 (New pctankimplatation ("T50"); t50pc. run (); // T50 on mobile T50 t50mobile = new T50 (New mobiletankimplatation ("T50"); t50mobile. run (); // t60 on PC t60 t60pc = new t60 (New pctankimplatation ("t60"); t60pc. run (); // t60 on mobile t60 t60mobile = new t60 (New mobiletankimplatation ("t60"); t60mobile. run ();}}

The running result is as follows:

 

If you want to add different platforms or models, you only need to add specific classes for the platforms and models. You can freely combine the models on which platforms to use. In this way, the complexity of the class structure is greatly reduced. The following two images are the best illustration.

Requirement changes when the bridge mode is not used

Changes in requirements after the bridge mode is used

Key points of the Bridge Mode

The Bridge Mode decouples the inherent binding relationship between abstraction and implementation using the "Combination relationship between objects", so that abstraction (tank model) and implementation (different platforms) they can be changed along their respective dimensions.

The so-called abstraction and implementation Change along their respective dimensions, that is, "subclass" them, such as subclasses of different tank models and subclasses of different platforms. After obtaining the sub-classes, you can combine them to obtain different models on different platforms.

The bridge mode is sometimes similar to a multi-inheritance scheme, but the multi-inheritance scheme often violates the single responsibility principle and has poor reusability. The bridge mode is better than multi-inheritance solutions.

The application of the bridge mode is generally in "two very strong changing dimensions". Sometimes, even if there are two changing dimensions, however, the changing dimensions in a certain direction are not drastic. In other words, the two changes do not result in a cross-slice and do not have to use the bridging mode.