I. Bridge Mode
The bridge mode is a very useful and complex mode. Familiarity with this mode is helpful for understanding the object-oriented design principles, including the "open-closed" principle (OCP) and the combination/aggregation Reuse Principle (CARP. Understanding these two principles helps to form correct design ideas and cultivate a good design style. Note: In the book "Java and mode", the bridge mode is not a frequently used mode. I don't agree with it. I think the bridge mode contains many key ideas of the design mode, so I have adopted Alan shalloway and James R. trott's point of view: the Bridge pattern is quite a bit more complex than the other patterns you just learned; it is also much more useful.
The purpose of the Bridge Model [gof95] when proposing the bridge model, it is pointed out that the purpose of the bridge model is to "decouple abstract action and implementation, so that the two can change independently ". This sentence has three keywords: abstraction, implementation, and decoupling.
Abstraction
The conceptual relationships that exist in multiple entities are abstract. As a process, abstraction is to ignore some information and treat different entities as the same entities [liskov94 ].
Implementation
The specific implementation given in abstraction is implementation.
Decoupling
Coupling is a strong association between two entities. Removing their strong associations is the relief of coupling, or decoupling. Here, decoupling means 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 an aggregation relationship, that is, change the strong association between them to a weak Association. Therefore, the so-called decoupling in the bridge mode refers to the use of a combination/aggregation relationship between the abstraction and implementation of a software system, rather than an inheritance relationship, so that the two can change relatively independently. This is the purpose of the bridge model.
Ii. Structure of the Bridge Model
Bridge Mode [gof95] is the object structure mode, also known as handle and body mode or interface mode. The figure below shows a schematic system structure that implements the bridge mode.
We can see that this system has two levels, namely:
1. abstract level structure composed of abstract roles and corrected abstract roles.
2. An implementation level structure composed of an implementation role and two specific implementation roles. The following roles are involved in the Bridge Mode:
Abstract action role: defines the abstract object and saves a reference to the implemented object.
Modify abstract roles: Expand abstract roles, and modify the abstract definitions of the parent class.
Implementor role: this role provides an interface for implementing the role, but does not provide a specific implementation. It must be noted that this interface is not necessarily the same as the interface definition of abstract roles. In fact, these two interfaces can be very different. An implemented role should only provide underlying operations, while an abstract role should only provide operations at a higher level based on underlying operations.
Concrete implementor role: this role provides the specific implementation of the role interface.
Iii. Modem Problems
I feel that the example of Bridge pattern in Agile Software Development-principles, models and practices is good. (The change encapsulation section in chapter 33 of Java and patterns is also well written. We recommend that you read it. It elaborates on design to interfaces in design patterns explained. 2) favor composition over inheritance. 3) Find What varies and encapsulate it .).
There are a large number of modem customer programs using the modem interface. The modem interface is implemented by several Derived classes hayesmodem, usroboticsmodem, and earniesmodem. It complies well with OCP, LSP, and dip. When a new type of modem is added, the client program of the modem will not be affected. It is assumed that this situation lasted for several years, and many modem client programs are using the modem interface. A non-dial modem is now available, called a dedicated modem. They are located at both ends of a dedicated connection. There are several new applications that use these dedicated modem, which do not require dialing. We call these users deduser. However, the customer wants all current modem client programs to use these dedicated modems. They do not want to change many modem customer applications, so they can have these modem customer programs dial fake phone numbers. If possible, we will change the system design as shown in. We separate the dialing and communication functions into two different interfaces. The original modem implements these two interfaces, and the modem client uses these two interfaces. Deduser only uses the modem interface, while dedicatemodem only implements the modem interface. But doing so will require us to change all modem customer programs-this is not allowed by the customer. One possible solution is to let dedicatedmodem derive from modem and implement the dial method and the hangup method as null, just like this: A few months later, there were already a large number of dedusers, at this time, the customer proposes a new change. To enable international phone numbers and credit card phone numbers, you must use the char [10] storage number in the existing dial to change it to a phone number of any length. Obviously, all modem client programs must be changed. The customer agreed to change the modem client program because they had no choice. The bad thing is, we have to tell deduser writers that they have to change their code! You can imagine how happy they are to hear this. They didn't need to call dial. This is the harmful and chaotic dependency that many projects will have. A kludge in a part of the system creates a harmful dependency, which eventually leads to problems in completely unrelated parts of the system. If you use the adapter mode to solve the initial problem, you can avoid this serious problem. Note that the pooled object still exists. The adapter still needs to simulate the connection status. However, all dependencies are initiated from the adapter. The collection body is isolated from the system and hidden from almost unknown adapters.
Bridge ModeThere is another way to look at this problem. Now there is another way to split the modem hierarchy. For example, this is not an ideal structure. Each time a new hardware is added, two new classes must be created-one for the dedicated scenario and the other for the dial-up scenario. Each time a new connection type is added, three new classes must be created, corresponding to three different hardware. If these two degrees of freedom are unstable at all, then a large number of derived classes will appear soon. The bridge mode is usually useful when the type hierarchy has multiple degrees of freedom. We can separate these hierarchies and combine them through bridges, rather than merging them. We divide the modem hierarchy into two layers. One represents the connection method, and the other represents the hardware. This structure is complex but interesting. Its creation does not affect the user of the modem and completely isolates the connection policy and hardware implementation. Each derived class of modemconnectcontroller represents a new connection policy. In the implementation of this policy, sendlmp, cancelmp, diallmp, and hanglmp can be used. The addition of new imp methods does not affect users. You can use ISP to add new interfaces to the connection control class. In this way, you can create a migration path. The Modem client program can follow this path to obtain an API that is higher than the dial and hangup levels.
4. Under what circumstances should the bridge model be usedAccording to the above analysis, the bridge mode should be used in the following situations:
- If a system requires more flexibility between the abstract role and the specific role of the component, it will avoid establishing static connections between the two layers.
- The design requires that any change to the role should not affect the client, or the change to the role should be completely transparent to the client.
- A component has more than one abstract role and actual role, and the system needs dynamic coupling between them.
- Although there is no problem in using inheritance in the system, the abstract roles and specific roles need to be changed independently, and the design requirements need to be managed independently.
James W. Cooper, C # Design Pattern
