Design Mode Study notes 7-Bridge Mode

Motivation : ThinkPad has multiple models, such as T43 and t60. Each model supports multiple working modes. Each model has different implementations in different modes. With the continuous development, there are more and more models and working models. How to separate ThinkPad from the changes in model and working mode so that they change independently, without introducing additional complexity (the complexity caused by the constant inheritance of the base class to generate different working modes on different models of ThinkPad )?

Application: Adapt to multi-dimensional changes of Objects

Structure

CodeImplementation

Namespace Designpattern. Bridge
{
Public   Abstract   Class ThinkPad
{
// The ThinkPad objects of different models are combined to implement related operation objects in different working modes, and the changes of related operations of the same object in different modes are transferred to the operation objects in different modes, it also supports any combination of different objects and different modes.
Protected Thinkpadmodeimp;

Public ThinkPad (thinkpadmodeimp)
{
This. Thinkpadmodeimp=Thinkpadmodeimp;
}

Public   Abstract   Void Start ();

Public   Abstract   Void Operate ();

Public   Abstract   Void Shutdown ();
}

Public   Class T43: ThinkPad
{
Public T43 (thinkpadmodeimp)
: Base (Thinkpadmodeimp)
{
}

Public   Override   Void Operate ()
{
Thinkpadmodeimp. operate1 ();
Thinkpadmodeimp. operate2 ();
//Do something else
}

Public   Override   Void Start ()
{
}

Public   Override   Void Shutdown ()
{
}
}

Public   Class T60: ThinkPad
{
Public T60 (thinkpadmodeimp)
: Base (Thinkpadmodeimp)
{
}

Public   Override   Void Operate ()
{
Thinkpadmodeimp. operate1 ();
Thinkpadmodeimp. operate2 ();
//Do something else
}

Public   Override   Void Start ()
{
}

Public   Override   Void Shutdown ()
{
}
}
}

/**/ /*
* Different ThinkPad operations in multiple modes
*/

Namespace Designpattern. Bridge
{
Public   Abstract   Class Thinkpadmodeimp
{
Public Abstract VoidOperate1 ();

Public Abstract VoidOperate2 ();
}

Public   Class Thinkpadmode1imp: thinkpadmodeimp
{
Public   Override   Void Operate1 ()
{
}

Public   Override   Void Operate2 ()
{
}
}

Public   Class Thinkpadmostmode2imp: thinkpadmodeimp
{
Public   Override   Void Operate1 ()
{
}

Public   Override   Void Operate2 ()
{
}
}
}

Namespace Designpattern. Bridge
{
Public   Class Thinkpadclient
{
Public   Void Operate ()
{< br> // here you can create an object in the application creation mode as needed
thinkpadmode1imp thinkpadmode1imp = New thinkpadmode1imp ();
t60 t60 = New t60 (thinkpadmode1imp);
}
}
}

Key Points:
1. This mode decouples the inherent binding relationship between abstraction and implementation by using the "Combination relationship between objects", so that abstraction (ThinkPad model) and implementation (Working Mode) they can be changed along their respective dimensions.
2. The so-called abstraction and implementation Change along their respective dimensions, that is, "subclass" them (for example, different ThinkPad subclasses and different working mode subclasses ). After each subclass is obtained, the ThinkPad model and working mode can be combined to obtain ThinkPad of different models and working modes.
3. This mode is sometimes similar to multi-integration solutions, but multi-inheritance solutions often violate the single responsibility principle of the class (that is, a class has only one reason for change), and the reusability is poor. The bridge mode is better.
4. This mode is generally used when an object faces changes in two very strong dimensions. Sometimes, even if there are two changed dimensions, however, The Changing Dimension in a certain direction is not violent-the changes in the two dimensions do not produce the results of the vertical and horizontal cross, and this mode is not necessary.