Design mode 07:bridge bridging mode (structural mode)

Bridge Bridging Mode (structural mode)

Abstraction and implementation

Abstractions should not be dependent on implementation details, and implementation details should be dependent on abstraction.

Abstract b stability, implementation details B change

The problem is that if abstract B is inherently unstable and likely to change because of its inherent causes, what happens?

For example

If we need to develop a tank game that supports both PC and mobile, the game will have the same function on both PC and mobile phone, all of the same type, facing the same demand changes, such as tank may have many different models: T50,t75,t90 ...

For the tank design, we can easily design a tank abstract base class:

    /// <summary>    ///Abstract Tank/// </summary>     Public Abstract classTank { Public Abstract voidShot ();  Public Abstract voidRun ();  Public Abstract voidTurn (); }    //various implementations     Public classT50:tank {//...    }     Public classT75:tank {//...    }     Public classT90:tank {//...}

Another reason for change

But the computer and the mobile phone graphics drawing, effective, operation and other implementation is completely different ... Therefore, for various types of tanks, to provide a variety of tanks on different platforms to achieve:

    //PC Platform Implementation     Public classPct50:t50 {//...    }     Public classpct75:t75 {//...    }     Public classPct90:t90 {//...    }    //Mobile Platform Implementation     Public classMobilet50:t50 {//...    }     Public classmobilet75:t75 {//...    }     Public classMobilet90:t90 {//...}

Such a design brings a lot of problems: there are a lot of duplicate code, the structure of the class is too complex, difficult to maintain, the most deadly is to introduce any new platform, such as the tank game on TV, will make the entire class hierarchy complex changes.

Motive (motivation)

Think of the crux of the problem: in fact, due to the inherent logic of the tank type, the tank type has two dimensions-one changing dimension is "platform change", and a change dimension is "model change".

How to deal with this "multidimensional change"? How can you use object-oriented technology to make the tank type easily evolve along the "platform" and "model" two directions without introducing additional complexity?

Intentions (Intent)

Separate the abstract parts from the real ones so that they can vary independently. --"Design pattern" GoF

code example:

    //Platform     Public Abstract classtankplatformimplementation { Public Abstract voidMovetankto (point to);  Public Abstract voidDrawtank ();  Public Abstract voidDoshot (); }    //PC Platform     Public classpctankimplementation:tankplatformimplementation { Public Override voidMovetankto (point to) {//...        }         Public Override voidDrawtank () {//...        }         Public Override voidDoshot () {//...        }    }    //Mobile Platform     Public classmobiletankimplementation:tankplatformimplementation { Public Override voidMovetankto (point to) {//...        }         Public Override voidDrawtank () {//...        }         Public Override voidDoshot () {//...        }    }

    /// <summary>    ///Abstract Tank/// </summary>     Public Abstract classTank {protectedtankplatformimplementation Tankimpl;  PublicTank (tankplatformimplementation tankimpl) { This. Tankimpl =Tankimpl; }         Publictankplatformimplementation Tankimpl {Get{return  This. Tankimpl;} Set{ This. Tankimpl =Tankimpl;} }         Public Abstract voidShot ();  Public Abstract voidRun ();  Public Abstract voidTurn (); }

    //various implementations     Public classT50:tank { PublicT50 (tankplatformimplementation Tankimpl):Base(Tankimpl) {} Public Override voidShot () {//...        }         Public Override voidRun () {//...        }         Public Override voidTurn () {//...        }    }     Public classT75:tank { PublicT75 (tankplatformimplementation Tankimpl):Base(Tankimpl) {} Public Override voidShot () {//...        }         Public Override voidRun () {//...        }         Public Override voidTurn () {//...        }    }     Public classT90:tank { PublicT90 (tankplatformimplementation Tankimpl):Base(Tankimpl) {} Public Override voidShot () {//...        }         Public Override voidRun () {//...        }         Public Override voidTurn () {//...        }    }

    // called     Public class App    {        publicstaticvoid  Main ()        {            tankplatformimplementation Tankimpl=new mobiletankimplementation (); // Phone platform Call            T50 tankt50=New  T50 (Tankimpl);        }    

Separate the changes of multiple dimensions in a thing so that they can vary independently

Several points of bridge mode

Bridge mode uses the "Composite relationship between objects" to decouple the inherent binding between abstraction and reality, so that abstractions (tank models) and implementations (different platforms) can evolve along their respective dimensions.

The so-called abstractions and implementations can change along their respective dimensions, i.e. "subclass" them, such as the tank-type chant class, and the different platform subclasses. Once the subclasses are available, they can be arbitrarily combined to obtain different models of different platforms.

Bridge mode is sometimes similar to multi-inheritance scenarios, but multiple inheritance schemes often violate the single principle of responsibility (that is, one class has only one reason for change) and reusability is poor. Bridge mode is a better solution than a multi-inheritance scheme.

Bridge mode is generally used in "two very strong change dimensions", sometimes even with two changing dimensions, but the dimension of change in one direction is not dramatic-in other words, two changes do not result in criss-crossing results, and bridge mode is not necessarily used.

Design mode 07:bridge bridging mode (structural mode)