Dot Net Design Patterns-Relationship between adapters, bridging, and appearance

I have been studying various design patterns over the past few days. When I learned the adapter, bridge, and appearance patterns, I found that there was a certain relationship between them, in fact, the mode is not suitable for a single existence. In our real programming life, it is often used in combination with several modes.

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 to integrate functions with third-party products. The method to adapt to the new type is to develop the adapter for this type, as shown below.

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. In the bridge mode, functions are extended through interface inheritance or inheritance ,.

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, so that they can be evolved separately, while the adapter mode is used after the design is complete, when it is found that the design completed classes cannot work together, the adapter mode can be used.
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 ,. This article provides some examples for your reference only.

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 constitute a bridge ,.

The same structure is often used in report-related applications. The report structure and report output mode can be completely separated, 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 method. If the output is in PDF format, Apis related to PDF must be called, which is beyond the control of the design, therefore, the adapter mode is used here.

3. Relationship between the adapter mode and the appearance Mode
The adapter mode is similar to the appearance mode, which encapsulates the existing storage system. However, the intention of these two models is completely different. The former enables the existing system to work collaboratively with the system being designed, while the latter provides a more convenient access interface for the existing 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. For example, the existing algorithm modules that cannot be modified and replaced as stipulated by the authority (the volumetric algorithm of the tank is defined by the National Authority of measurement, you need to use a specific module), and you may upgrade it in the future. In this case, you can use the adapter mode.
The use of the appearance mode is sometimes difficult to grasp. The definition of the appearance interface is closely related to 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 implemented only by calling the original system, and the encapsulation is not 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. Shows the structure in this case.

4. Summary
We have discussed the relationship between the adapter mode, the bridge mode, and the appearance mode. The adapter mode is often used when it needs to work with a third-party API. Today, more and more feature integration needs, and the usage frequency of this mode is getting higher and higher, in particular, the combination of the Bridge Mode and the adapter appears more and more frequently in the design, and has almost become a new mode.
The appearance mode is another common pattern in system evolution. In some cases, it is similar to the adapter mode. However, in general, the appearance mode is more specific to objects.