1. Overview
In software systems, some types of software systems have two or more dimensional changes due to their own logic. How can we deal with such "multi-dimensional changes "? How can we use object-oriented technology to make this type easily change in multiple directions without introducing additional complexity?
Example 1: Suppose we need at least four shape classes to draw a rectangle, a circle, an ellipse, or a square, but if the drawing needs to have different colors, such as red, green, and blue, there are at least two solutions:
• The first design scheme is to provide a set of color versions for each shape.
• The second design scheme is to combine shapes and colors based on actual needs.
Solution 1:
Solution 2:
For systems with two changing dimensions (that is, the reasons for two changes), solution 2 is used to design systems with fewer classes, and system expansion is more convenient. Solution 2 is the application of the bridge mode. In the bridge mode, the inheritance relationship is converted into an association relationship, which reduces the coupling between classes and reduces the amount of code writing.
Example 2A common switch-controlled electric lamp, fan, and so on are all examples of bridging. The purpose of the switch is to turn the device on or off. The actual switch can be a simple double-knife zipper switch or a dimming switch.
2. Problem
How can we cope with this "multi-dimensional change "? How can we use object-oriented technology to make this type easily change in multiple directions without introducing additional complexity?
3. Solution
Bridge Connection Mode: Separates abstract and implementation parts so that they can all change independently. It is a structural mode, also known as the handle and body mode or interface mode. When an abstraction may have multiple implementations, inheritance is usually used to coordinate them. Abstract class definition for this abstract interface. The specific subclass is implemented in different ways, but this method is sometimes not flexible enough. The Inheritance Mechanism binds the abstract Part with its line of sight, making it difficult to modify, expand, and use the abstract Part and implementation part independently.
To understand the bridge mode, we need to understand how to decouple abstract action and implementation so that the two can change independently. • Abstraction: Abstraction ignores some information and treats different entities as the same entities. In object orientation, the process of extracting the common properties of objects to form classes is abstract. • Implementation: The specific implementation provided for abstraction is implementation. abstraction and implementation are a pair of reciprocal concepts. The objects produced by implementation are more specific than those produced by abstraction, is the product of further concrete abstraction. • Decoupling: decoupling is to free up coupling between abstraction and reality, or change strong associations between them into weak associations, change the inheritance relationship between two roles to the association relationship. In the bridge mode, decoupling refers to the Association (combination or aggregation) between the abstraction and implementation of a software system, rather than the inheritance relationship, so that the two can change relatively independently, this is the purpose of the bridge mode.
4. Applicability
1). You do not want to have a fixed bonding relationship between the abstraction and its implementation. For example, the implementation part of the program at runtime can be selected or switched.
2) Class abstraction and its video can be expanded by generating sub-classes. In this case, the bridge mode enables you to use different abstract interfaces.
And the implementation part, and expand them.
3) Modifications to an abstract implementation should not affect the customer, that is, the customer's Code does not need to be re-compiled.
4) You want to completely hide the abstract implementation part of the customer.
5). You want to share multiple implementations, but at the same time, the customer is not required to know this.
5. Structure
6. Composition of the build Mode
Abstract action: defines the abstract class interface and maintains a pointer to an object of the implementor type.
Extension abstract class (refined1_action): expands the interface defined by the extension action
Implementation class interface (implementor): defines the interface for implementing classes. This interface does not have to be exactly the same as the interface for implementing actions. In fact, these two interfaces can be completely different. Generally, the implementor interface only provides basic operations, while the role Action defines high-level operations based on these basic operations.
Concreteimplementor: implements the implementor interface and defines its specific implementation.
7. Effect
The bridge mode has the following advantages:
1) Separation interface and its implementationAn implementation may not always be bound to an interface. The implementation of an abstract class can be configured at runtime, and an object can even be changed at runtime. Separating the compile action from implementor helps reduce the dependency on partial compilation time. When you change an implementation class, you do not need to recompile the compile action class and its client program. To ensure the binary compatibility between different versions of a class library, this feature must be applied. In addition, the separation of interfaces and implementations helps to Form layers to produce a better structured system. The High-level part of the system only needs to know the role action and implementor.
2) Improve scalabilityYou can expand the hierarchical structure of the role action and implementor independently.
3) make the details transparent to the customerYou can hide implementation details from customers, such as sharing implementor objects and corresponding reference counting mechanisms (if any ).
Disadvantages of the Bridge Mode • the introduction of the Bridge Mode increases the system's understanding and design difficulty. Since the aggregation association is established on the abstraction layer, developers are required to design and program the abstraction. • The Bridge mode requires correct identification of two independent dimensions in the system, so the scope of use has certain limitations.
8. Implementation
Simulated brush:
Now we need to provide 3 models of paint brushes, which can draw 5 different colors. If you use crayons, we need 3*5 = 15 crayons, that is to say, you must prepare 15 specific crayons. If you use a brush, you only need three types of brush, plus five pigment boxes. You can use 3 + 5 = 8 types to implement 15 crayons.
In fact, the key difference between a crayon and a brush is whether the pen and color can be separated. Decoupling abstract action and implementation so that the two can change independently ". The key lies in the decoupling. The color of a crayon is inseparable from that of a crayon. Therefore, 15 crayons of different colors and sizes must be used to draw a picture. The brush and paint can be well decoupled, and their independent changes simplify the operation. Here, the concept of abstraction layer is: "paint with paint brush", while in implementation, there are five kinds of paint: big, medium, small, and medium, red, green, blue, black, and white, therefore, a combination of three or five types can appear. Each participant (brush and paint) can freely convert their own degrees of freedom.
Because the pen and color cannot be separated, the degree of freedom between the pen and the color cannot be changed separately, so that only 15 types of objects can be created to complete the task.
The Bridge Mode converts the inheritance relationship into a composite relationship, which reduces the coupling between systems and reduces the amount of code writing.
UML
Code implementation:
- <? PHP
- ******** ******************/
- /**
- *
- * Initiate action abstract class Interface
- * @ Author guisu
- *
- */
- Abstract class brushpen1_action {
- Protected $ _ implementorcolor = NULL;
- /**
- *
- * Enter description here...
- * @ Param color $ color
- */
- Public Function setimplementorcolor (implementorcolor $ color ){
- $ This-> _ implementorcolor = $ color;
- }
- /**
- *
- * Enter description here...
- */
- Public abstract function operationdraw ();
- }
- /****************************** Refined1_action ******** ******************/
- /**
- *
- * Expanded by batch action;
- * @ Author guisu
- *
- */
- Class bigbrushpenrefined1_action extends brushpen1_action {
- Public Function operationdraw (){
- Echo 'Big and', $ this-> _ implementorcolor-> bepaint (), 'Drawing ';
- }
- }
- /**
- *
- * Expanded by the processing action;
- * @ Author guisu
- *
- */
- Class middlebrushpenrefined?action extends brushpen=action {
- Public Function operationdraw (){
- Echo 'midddle', $ this-> _ implementorcolor-> bepaint (), 'Drawing ';
- }
- }
- /**
- *
- * Expanded by fill action;
- * @ Author guisu
- *
- */
- Class smallbrushpenrefined?action extends brushpen=action {
- Public Function operationdraw (){
- Echo 'smalland', $ this-> _ implementorcolor-> bepaint (), 'Drawing ';
- }
- }
- /***************************** Implementor ******** ******************/
- /**
- * Implementor)
- *
- * @ Author Mo-87
- *
- */
- Class implementorcolor {
- Protected $ value;
- /**
- * Coloring
- *
- */
- Public Function bepaint (){
- Echo $ this-> value;
- }
- }
- /**************************** Oncrete implementor ******* *******************/
- Class oncreteimplementorred extends implementorcolor {
- Public Function _ construct (){
- $ This-> value = "red ";
- }
- /**
- * Overwrite
- */
- Public Function bepaint (){
- Echo $ this-> value;
- }
- }
- Class oncreteimplementorblue extends implementorcolor {
- Public Function _ construct (){
- $ This-> value = "blue ";
- }
- }
- Class oncreteimplementorgreen extends implementorcolor {
- Public Function _ construct (){
- $ This-> value = "green ";
- }
- }
- Class oncreteimplementorwhite extends implementorcolor {
- Public Function _ construct (){
- $ This-> value = "white ";
- }
- }
- Class oncreteimplementorblack extends implementorcolor {
- Public Function _ construct (){
- $ This-> value = "black ";
- }
- }
- /**
- *
- * Client program
- * @ Author guisu
- *
- */
- Class client {
- Public static function main (){
- // Small stroke red
- $ Objr1_action = new smallbrushpenrefined1_action ();
- $ Objr1_action-> setimplementorcolor (New oncreteimplementorred ());
- $ Objr1_action-> operationdraw ();
- }
- }
- Client: Main ();
Cross-platform video players: the platform and video files of different formats are changed in two dimensions:
9. Bridge Mode and other related modes
1) Abstract Factory (Abstract Factory mode can be used to create and configure a specific bridge mode.
2) the adapter mode is used to help irrelevant classes to work collaboratively. It is usually used only after the system is designed. However, the bridge mode is used at the beginning of the system, which allows abstract interfaces and implementations to be changed independently.
3) The difference between the bridge mode and Decoration:
Decoration mode:
These two models are designed to reduce the number of child classes and avoid complex inheritance relationships. However, they have different solutions. In the decoration mode, the Child classes are placed in separate classes to meet the needs of new functions, when we encapsulate the classes that describe the new functions into the objects of the base classes, we get the required subclass objects. These classes that describe the new functions can be combined to implement many functional combinations.
Bridging Mode:
The Bridge Mode abstracts the implementation details of the original base class, constructs it into an implementation structure, and then transforms the original base class into an abstract level structure, in this way, the system can be changed independently in multiple dimensions.
10. Summary
The bridge mode is a very useful and complex mode. It is well compliant with the open-closed principle and the preferential use of objects, rather than inheriting these two object-oriented principles.
Reference: 1. http://blog.csdn.net/hguisu/article/details/7529194.