Simple Design Mode-Bridge Mode (2)

Today, I have been restless and have been troubled by some things. I hope to have a good process and result, not my own dreams. Let's take a look at the bridge mode. I personally feel that this mode is a relatively easy-to-understand mode, but it still requires some experience in real application.

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? This requires 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.


Pattern definition: Bridge pattern: separates abstract parts from their implementations so that they can all change independently. It is an object structure mode, also known as the handle and body mode or interface mode. (Bridge pattern: decouple an independent action from its implementation so that the two can vary independently .)

Structure:

Invalid action

Define abstract Interfaces

This interface contains the implementor interface that implements specific behaviors and features

Refined Response Action

The subclass of the abstract action interface is still an abstract object name.

Implementor

Application interface that defines specific behaviors and features

Concreteimplementor

Implement implementor Interface

Mode Analysis: 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.

Code implementation: In this example, it is more appropriate to use paint brushes and colors:
Invalid action

Public abstract class brush {color mcolor; Public brush (color) {mcolor = color;} // The default brush is black public brush () {mcolor = new blackcolor ();} public void setcolor (color) {mcolor = color;} public abstract void draw ();}

Refined Response Action

Small pen:

public class SmallBrush extends Brush {public SmallBrush(){super();}public SmallBrush(Color color) {super(color);}@Overridepublic void draw() {System.out.println(" in smallBrush, begin to draw");mColor.draw();}}

Medium pen:

public class MiddleBrush extends Brush {public MiddleBrush() {super();}public MiddleBrush(Color color) {super(color);}@Overridepublic void draw() {System.out.println(" in MiddleBrush, begin to draw");mColor.draw();}}

Large Number pen:

public class BigBrush extends Brush {public BigBrush() {super();}public BigBrush(Color color) {super(color);}@Overridepublic void draw() {System.out.println(" in BigBrush, begin to draw");mColor.draw();}}

Implementor

public interface Color {void draw();}

Concreteimplementor Red:

public class RedColor implements Color {@Overridepublic void draw() {System.out.println("this is red color...");}}

Black:

public class BlackColor implements Color {@Overridepublic void draw() {System.out.println("this is black color...");}}

Blue:

public class BlueColor implements Color {@Overridepublic void draw() {System.out.println("this is blue color...");}}

Green:

public class GreenColor implements Color {@Overridepublic void draw() {System.out.println("this is green color...");}}

Client

Public class client {public static void main (string [] ARGs) {// generates five colors: Color blackcolor = new blackcolor (); color bluecolor = new bluecolor (); color greencolor = new greencolor (); color redcolor = new redcolor (); // generates three types of Brushes: smallbrush = new smallbrush (redcolor); brush middlebrush = new middlebrush (); // set it to the blue color middlebrush. setcolor (bluecolor); // The default black color: Brush bigbrush = new bigbrush (); // start painting smallbrush. draw (); middlebrush. draw (); bigbrush. draw (); // change the pen to the green color, and the middle to the Black bigbrush. setcolor (greencolor); middlebrush. setcolor (blackcolor); bigbrush. draw (); middlebrush. draw ();}}

Extension:

If we need to draw different images with different pen models of different colors: graphic interface:

public interface Shape {void create();}

Graphic implementation: Square:

public class Square implements Shape {@Overridepublic void create() {System.out.println("Square");}}

Circle:

public class Circle implements Shape {@Overridepublic void create() {System.out.println("cricle");}}

Heart shape:

public class HeartShaped implements Shape {@Overridepublic void create() {System.out.println("love heart-shaped");}}

Modify the paint brush class:

Public abstract class brush {color mcolor; Public brush (color) {mcolor = color;} // The default brush is black public brush () {mcolor = new blackcolor ();} public void setcolor (color) {mcolor = color;} public void drawshape (shape) {draw (); shape. create ();} public abstract void draw ();}

Then the client calls:

Public class client {public static void main (string [] ARGs) {// generates five colors: Color blackcolor = new blackcolor (); color bluecolor = new bluecolor (); color greencolor = new greencolor (); color redcolor = new redcolor (); // generates three types of Brushes: smallbrush = new smallbrush (redcolor); brush middlebrush = new middlebrush (); // set it to the blue color middlebrush. setcolor (bluecolor); // The default black color: Brush bigbrush = new bigbrush (); // start painting smallbrush. draw (); middlebrush. draw (); bigbrush. draw (); // change the pen to the green color, and the middle to the Black bigbrush. setcolor (greencolor); middlebrush. setcolor (blackcolor); bigbrush. draw (); middlebrush. draw (); // draw a red smallbrush with a small number. drawshape (New heartshaped (); // a medium stroke with a black circle middlebrush. drawshape (new circle (); // draw a green square bigbrush with a large stroke. drawshape (New Square ());}}

Advantages:
Separating abstraction and implementation

The Bridge Mode separates the abstract part and the implementation part, which greatly improves the flexibility of the system. Let the abstract Part and implementation part be separated and define interfaces separately, which helps to layer the system and generate a better structured system. For the high-level part of the system, you only need to know the abstract part and the interface of the implementation part.

Better scalability

Because the Bridge Mode separates the abstract part and the implementation part and defines interfaces separately, the abstract part and the implementation part can be separately expanded without affecting each other, this greatly improves the scalability of the system.

Dynamic switchover implementation

Since the Bridge Mode separates the abstract part and the implementation part, dynamic selection and specific implementation can be achieved when bridging is implemented. That is to say, an implementation is no longer bound to an abstract interface, and can be dynamically switched during running.

Reduces the number of child classes.

According to the previous article, if there are two changing latitudes, if the inheritance implementation method is adopted, the product of the changeable quantities on the two latitudes is required; the bridge mode is used to achieve this. It requires a variable number and sub-classes at two latitudes. This can significantly reduce the number of child classes.

Disadvantages of the Bridge Mode

1. The introduction of the Bridge Mode increases the understanding and design difficulty of the system. Since the aggregation association is established on the abstraction layer, developers are required to design and program the abstraction.
2. The bridge mode requires correct identification of two independent dimensions in the system, so the scope of use has certain limitations.

Applicable Environment

If you do not want to use a fixed binding relationship between the abstract part and the implementation part, you can use the bridge mode to separate the abstract part and the implementation part, then, you can dynamically set the specific implementation required for the abstract part during the running of the program. You can also dynamically switch the specific implementation.

If both the abstract part and the implementation part can be expanded, the bridge mode can be used to allow the abstract part and the implementation part to change independently, so as to flexibly expand separately, instead of mixing together, the scaling side will affect the other side.

If you want to implement some modifications without affecting the customer, you can use the bridge mode. Because the customer is running an abstract-oriented interface, modifications to the implementation part can be independent of the abstract part, without affecting the customer. It can also be said that the modification is transparent to the customer.

If an inherited implementation scheme is used, many sub-classes will be generated. In this case, you can consider using the Bridge Mode to analyze the reasons for functional changes and see if the data can be separated into different latitudes, then they are separated in the bridging mode to reduce the number of child classes.

Mode Extension

Adapter mode and Bridge ModeThe bridge mode and the adapter mode are used in different stages of design. The bridge mode is used in the preliminary design of the system. For classes with two independent changing dimensions, they can be divided into abstract and actual roles, so that they can be changed separately. After preliminary design, the adapter mode can be used when the system and existing classes cannot work together. However, sometimes the adapter mode needs to be considered at the initial stage of the design, especially when a large number of third-party application interfaces are involved.
Bridging Mode and Policy Mode

These two models have great similarities.

If you want to simplify the abstract part of the bridge mode, do not extend the bridging action temporarily, that is, remove refined1_action.

Although these two models are similar, they are still different. The main purpose of the pattern is different. The policy pattern aims to encapsulate a series of algorithms so that these algorithms can be replaced with each other. The purpose of the bridging pattern is to separate the abstract part and the implementation part, so that they can be changed independently. Through the above structure, we can see that the bridge mode and the policy mode are so similar. You can regard the context of the policy mode as the object using the interface, while strategy is an interface. The specific implementation of the policy is equivalent to the specific implementation of the interface. In this case, in some cases, the bridge mode can be used to simulate the implementation of the Policy mode function.

Bridging Mode and status Mode

In terms of the mode structure, the state mode and the policy mode are the same. Therefore, the relationship between the two modes is basically similar to that between the bridge mode and the policy mode.

The purpose of the state mode is to encapsulate the behavior corresponding to the state and change the behavior of the object when the internal state changes.

Bridge Mode and template method mode

These two models have similarities.

Although the standard template method mode is implemented by inheritance, the template method can also be implemented through the callback interface. If the implementation of the interface is independent, it is similar to the template method to call the specific implementation method through the interface. This structure is similar to the simplified Bridge Mode.

You can use the bridge mode to simulate the template method mode. If you define a method in the implementation of the jsonaction object, the method is a fixed algorithm skeleton, that is, the method is equivalent to the template method. In the template method mode, the undefined implementation step is delayed to the subclass implementation; now in the bridge mode, the undefined implementation step is delegated to the specific implementation part for completion, some interfaces are implemented through callback to complete some steps in the algorithm skeleton. In this way, you can use the bridge mode to simulate the implementation of the template method mode function.

The bridge mode is used to simulate the functions of implementing the template method mode. Another potential benefit is that the template method can be easily expanded and changed. In the standard template method, a problem is that when the template changes, all subclasses need to change, which is very inconvenient. This is not the case if you use the bridge mode to implement similar functions.

In addition, the bridge mode can simulate the functions implemented by the template method mode to implement specific business functions. It does not mean that the bridge mode and the template method mode will become the same, or the bridge mode can replace the template method mode. Note that their functions, purposes, and essential ideas are different.

Bridge Mode and abstract factory Mode