1. Differences and connections between the adapter mode and the Bridge Mode
The adapter mode and bridge mode both indirectly reference objects. Therefore, the system can be more flexible. in implementation, requests are sent from an interface other than itself to the referenced object.
The difference between the two modes is that the use cases are different. The adapter mode mainly solves the matching problem between two existing interfaces. In this case, the implementation of the adapted interfaces is often a black box. We don't want to, nor can we modify this interface and its implementation. At the same time, it is impossible to control its evolution, as long as the related objects can work together with the system-defined interfaces. The adapter mode is often used for function integration with third-party products. The method to adapt to the new type is to develop the adapter for this type, as shown in:
The bridge mode is different. The interfaces involved in the bridge are stable. You can extend and modify the classes in the bridge, but cannot change the interfaces. The Bridge Mode implements function expansion through interface inheritance or class inheritance. As shown in:
According to gof, the Bridge Mode and adapter mode are used at different stages of design. The bridge mode is used at the early stage of design, that is, when designing classes, class planning is divided into two categories: logic and implementation, they can evolve separately, while the adapter mode is used after the design is complete and the adapter mode can be used when the classes that have been designed cannot work collaboratively. However, in many cases, the use of the adapter mode should be considered at the initial stage of the design, such as when a large number of third-party application interfaces are involved.
2. Combination of the adapter mode and the Bridge Mode In practical applications, the bridging mode often appears in the same way as the adapter mode, as shown in:
This often occurs when other systems are required to provide implementation methods. A typical example is data collection in industrial control. The underlying data collection interfaces provided by different industrial control manufacturers are usually different. Therefore, the upper-layer software design cannot predict what interfaces may be encountered. To this end, you need to define a common collection interface and then develop the corresponding adapter for the specific data collection system. Data storage needs to call the data collection interface to obtain data, and data can be stored in relational databases, real-time databases, or files ,. The data storage interface and data collection structure are bridging, as shown in: the same structure is often used in report-related applications. The report structure and report output mode can be completely separated, as shown in:
As shown in, the report output can be abstracted separately from the specific form of the report. However, report output depends on the specific output mode. If you want to output the report in PDF format, you need to call the PDF-related API, which is beyond the control of the design. Therefore, the adapter mode is required here.
3. Relationship between the adapter mode and the appearance Mode The adapter mode is similar to the appearance mode, which is used to separate existing systems. However, the two modes have different intentions. The former enables the existing system to work together with the system being designed, while the latter provides a more convenient access interface for the video memory system. Simply put, the adapter mode is post-design, while the appearance mode must be pre-designed because the system depends on the appearance. In short, the adapter mode does not introduce new interfaces, while the appearance mode defines a new interface. The adapter mode is used for function integration with a small granularity, such as the existing Algorithm Module, which may be upgraded in the future. You can use the adapter mode. The use of the appearance mode is sometimes difficult to grasp. The definition of the appearance interface has a great relationship with the designer's understanding of the business. If the interface design is too complex, it is better to directly call the original system. If the interface design is too simple, some functions can be achieved only by calling the original system, and the purpose of sub-installation cannot be achieved. In this case, first consider the stability of the encapsulated system. If the system is in the evolutionary stage, the interface definition needs to be more complex to expose more interfaces. In this case, the appearance mode is more like a large-granularity adapter. When the encapsulated system evolves, a new appearance object is required, which acts as an adapter, as shown in the following figure:
SummaryThe adapter mode is often used in scenarios where third-party APIs are required to work collaboratively. Today, more and more feature integration requirements are required, in particular, the combination of the Bridge Mode and the adapter mode appears more and more frequently in the design, almost becoming a new design mode. The appearance pattern is another common pattern in system evolution. In some cases, it is similar to the adapter pattern, but in general, the appearance pattern targets a larger object granularity. References:. NET and Design Patterns