Java design pattern-Bridge pattern

Java design pattern-Bridge pattern
Overview

Bridge is used to separate abstract parts from implementation parts so that they can change in multiple dimensions. This sentence is easy to understand, but after learning the bridge model, I have some questions. Now I can figure it out. Now I am sending out the design ideas of the bridge model together with my questions. I hope it will be helpful to you.

Scenario

It is assumed that there are a variety of different TV models on the market, and some different remote control manufacturers. Remote Control manufacturers need to produce remote control for these TVs. However, there are too many TV models, some TV models are too complicated, and even some different TV models will appear in the future.

Common aggregation scheme

In this general solution, the remote control manufacturer must produce a remote control for each TV set. The class diagram is as follows:

Each specific Remote Control inherits or implements the abstraction or interface of the remote control. In addition, each specific Remote Control aggregates its own TV interface. This solution can solve the problem and solve the correspondence between the remote control and the TV. However, there is a problem, as mentioned in the above scenario, if there are some new TVs, then the manufacturer that produces the remote control has to produce a new remote control. In this way, the number of remote controls is not difficult to grasp, but the design is complicated.

Bridge Mode

The above general aggregation solution cannot solve the general problem of remote control and cannot be compatible and adapted to new models. In this case, there will be multi-dimensional extension in the abstraction or implementation, we must re-design the code structure. The following describes how the Bridge Mode solves this problem.

Definition

Separates abstract actions from Implementor so that they can be changed independently.

Analysis

The application scenario of the bridge mode is that there may be multi-dimensional changes to an abstraction or implementation. Just like the remote control instance above, we may have different producers in the abstract of the remote control; in the realization of the TV, we may find that such devices may be RCA and Sony. The bridge mode allows the remote control abstraction and television realization to change in multiple dimensions in their respective directions without worrying about other things.
I also analyzed that the general aggregation solution is unreliable. It can solve some problems, but it is cumbersome and unnecessary.
Here is an example that everyone may be familiar. For example, the relationship between the Java program we are writing and the running platform. We can have a lot of Java programs, and the running platform can also be Windows, Linux or Mac. Our Java program needs to be executed on all platforms, and every platform must ensure that all Java programs can be implemented.

Class Diagram

Let's use the abstract class of the remote control to aggregate the interface of the TV. Because TVs all implement the TV interface, the abstract class of the remote control aggregates all the TV sets. In this way, no matter how the TV model changes, the remote control can continue to work without modification.

Note: At that time, I had a small question: why does our TV interface not aggregate to the subclass of the remote control, but to the abstract class of the remote control? That is to say, do I need an abstract class for remote control?
Now, if the RemoteControl abstract class does not exist here, ConcreteRemote will hold the TV interface, but it is difficult to expand in the remote control dimension. The best thing about the bridge mode is that it allows multi-dimensional abstraction and implementation to be expanded in multiple dimensions.

Logical implementation

You can write Java code based on the class diagram above.

TV. java

public interface TV {    public void on();    public void off();    public void tuneChannel(int channel);}

RCA. java

Public class RCA implements TV {@ Override public void on () {System. out. println ("RCA opened") ;}@ Override public void off () {System. out. println ("RCA disabled");} @ Override public void tuneChannel (int channel) {System. out. println ("switched to channel +" channel ");}}

Sony. java

Public class Sony implements TV {@ Override public void on () {System. out. println ("Sony opened") ;}@ Override public void off () {System. out. println ("Sony opened");} @ Override public void tuneChannel (int channel) {System. out. println ("switched to channel +" channel ");}}

RemoteControl. java

public abstract class RemoteControl {    protected TV tv = null;    public RemoteControl(TV _tv) {        this.tv = _tv;    }    public abstract void on();    public abstract void off();    public void setChannel(int channel) {        if (tv != null) {            tv.tuneChannel(channel);        }    }}

ConcreteRemote. java

public class ConcreteRemote extends RemoteControl {    private int currentStation = 0;    private final int MAX_STATION = 25;    public ConcreteRemote(TV _tv) {        super(_tv);    }    @Override    public void on() {        tv.on();    }    @Override    public void off() {        tv.off();    }    public void setChannel(int channel) {        currentStation = channel;        super.setChannel(currentStation);    }    public void nextChannel() {        currentStation = (MAX_STATION + currentStation + 1) % MAX_STATION;        super.setChannel(currentStation);    }    public void previousChannel() {        currentStation = (MAX_STATION + currentStation - 1) % MAX_STATION;        super.setChannel(currentStation);    }}

Mode Evaluation

Advantages	Disadvantages
The realization of the TV is decoupled, and it is no longer permanently bound to the remote control.	Relatively complex
The remote control and TV can be expanded independently without affecting the other party.

Ref Head First design model