First, the primer
Bright mode is the last structural mode in 23 modes I introduced. It is a moderate function that is very powerful and suitable for a variety of situations.
Second, definition and structure
GOF defines the bridge mode in "Design Mode" as: separating the abstraction section with its implementation, so that they can change independently. The abstract part and achieved part here are not the relationship between the parent class and subclasses, interfaces and implementation classes, but a combination relationship. That is, the implementation portion is called by the abstraction part to complete (implementation) the function of the abstract portion.
In the book "Thinking In Patterns with Java", the author is called "front-end" in the author called "Front-end"), and the implementation part is called "back-end". This name is much better than what abstraction.
The bridge mode consists of the following four characters:
1) Abstraction Roles: It defines an abstract class interface and maintains a reference to an implementation (IMPLEMENTOR) role.
2) Accurate Abstract Roles: Implement and expand the interface defined by the abstract role.
3) Implementor Role: The interface for implementing the class is given. The interfaces here are inconsistent with the interfaces in the abstract role.
4) ConcreteImplementor Role: The specific implementation of the implementation role definition interface is given.
it
Placent with a class map is clearer:
But what is the structure give us? ?
In system design, it is always full of variables, which is an accidental anti-cautious. For example, the customer representative may request to modify a certain requirement, add some function, and so on. In the face of such changes, you can only go to modify design and code, and start a new round of testing ...
What kind of way is it possible to solve the impact of the change in the system? You can analyze the types of changes, define the constant frames to use the abstract class, and then achieve the changed content using the specific subclass. This is just an abstract class for customers, which avoids the impact of changes in the existing interfaces in the abstract class, narrowing the impact of changes. But this may result in an explosion of subclasses and are not very flexible at some time.
But when you have changed, or have a certain repetitive and combination relationship, we may take these behaviors and provide them with an interface, and then provide the service to the original child in a combination. class. This reaches the rear end independent changes in the front end and the used, and also reuses the rear end.
In fact, this is the birth of the bridge mode.
Third, instance
I now use the bridge mode application is the Java AWT framework. People who have used Java AWT know that software interfaces developed under different systems have unique style. At the time of using the API using the API, there is no distinction between different systems at all, you will not need to care about this. The AWT is just using bridge mode to do this.
However, I am not familiar with the code of AWT, so there is no way to explain here. Below can only give a common teaching code: (
The following code comes from "Thinking In Patterns with Java":
// Abstract part (front end) Abstract role
Class abstraction {
/ / Maintain a reference to the implementation of the implementation (Implementor)
PRIVATE IMPLEMENTATION IMPLEMENTATION; Public Abstract (Implementation IMP) {
IMPLEMENTATION = IMP;
}
/ / The front end (abstract part) should be defined below
Public void service1 () {
// Use the rear end (implementation part) Existing interface
// Combination implementation function
Implementation.facility11 ();
Implementation.facility2 ();
}
Public void service2 () {
Implementation.facility2 ();
Implementation.facility3 ();
}
Public void service3 () {
Implementation.facility11 ();
Implementation.facility2 ();
Implementation.facility4 ();
}
// for use by Subclasses:
protected importation getimplementation () {
Return IMplement;
}
}
// Exact abstract role of abstract part (front end)
Class clientService1 extends abstraction {
Public ClientService11 (Implementation IMP) {Super (IMP);
// combine a function using the method provided by the abstract role
// This is why the exact abstract role (correct abstract role)
Public void servicea () {
Service1 ();
Service2 ();
}
Public void serviceb () {
Service3 ();
}
}
/ / Another precise abstract role, and the same is omitted above
Class clientService2 extends abstraction {
. . . .
/ / Here is a functionality of directly through the implementation of the part
Public void servicee () {
GetImplementation (). facility3 ();
}
}
/ / Implement part (rear end) implementation role
Interface implementation {
/ / This interface is only defined a certain interface
Void facility1 ();
Void facility2 ();
Void facility3 ();
Void facility4 ();
}
/ / The specific implementation role is to implement the interface provided by the role.
/ / And complete a certain function
/ / Omitted here
Class Implementation1 Implements IMPLEMENTATION {
. . .
It also reflects a point in the program: that is, not only the interface provided by the partial and abstract parts can be completely different; and the inside, the interface inside the abstract part can be completely different. But the implementation part needs to provide similar functions.
Fourth, use environment and advantage
From the bridge mode we analyzed above, you can see that the bridge mode should apply to the following environment:
1) When there are multiple places in your system to use similar behavior, or when multiple similar behaviors are combined, you can consider using bridge modes to increase reuse, and reduce subclasses generated due to behavior.
2) A variety of behaviors in the system may have several different trends. In order to effectively encapsulate, it can be considered to take into account the behavior of the class.
3) Of course, the situation above may be the case, and behavior may be used by different similar classes, or consider using bridge mode to implement.
The bridge mode uses a combination of low coupling instead of inheritance, making it a lot of benefits: 1) Package the portion that may vary, so that the impact of changes is minimized, do not compile unnecessary code.
2) Abstract parts and achieve parts can be changed separately, and each part of the expansion does not destroy the bridge mode to stand up.
3) For the client program, your implementation details are transparent.
Bruce Eckel is mentioned in "Thinking In Patterns with Java", you can use the bridge mode as a framework that helps you encode the front and backend independent changes.
Five, expand
In the Book of Design Mode, you will mention the use of abstract factory modes to create and configure a bridge mode. The factory method mode is also used in the above example to obtain a specific implementation portion.
Six, summary
The above has written my understanding of bridge mode. If there is anything wrong, please refer to it!
