The relationship between adapter, bridge and appearance three modes

Both the adapter mode and the bridge mode are indirect reference objects, so the system can be made more flexible, and both involve making a request to the referenced object from an interface other than itself.

  The difference between the two modes lies in the different usage scenarios. The adapter mode mainly solves the matching problem between two existing interfaces. In this case, the implementation of the adapted interface is often a black box. We do not want to and cannot modify this interface and its implementation. It is also impossible to control its evolution, as long as the related objects work with the interface defined by the system. The adapter pattern is often used for functional integration with third-party products, and the way to use this pattern to accommodate the addition of new types is to develop adapters for this type.

[@more@]

  I have been studying various design patterns in the past few days. When I learned about the adapter pattern, the bridge pattern and the appearance pattern pattern, I found that there is a certain relationship between them. In fact, the pattern does not exist alone. In our reality In programming life, several patterns are often used in combination.

The difference and connection between adapter mode and bridge mode

  Both the adapter mode and the bridge mode are indirect reference objects, so the system can be made more flexible, and both involve making a request to the referenced object from an interface other than itself.

  The difference between the two modes lies in the different usage scenarios. The adapter mode mainly solves the matching problem between two existing interfaces. In this case, the implementation of the adapted interface is often a black box. We do not want to and cannot modify this interface and its implementation. It is also impossible to control its evolution, as long as the related objects work with the interface defined by the system. The adapter pattern is often used for functional integration with third-party products, and the way to use this pattern to accommodate the addition of new types is to develop adapters for this type.
           
  The bridge mode is different. The interface participating in the bridge is stable, and the user can extend and modify the classes in the bridge, but cannot change the interface. The bridge mode implements function extension through interface inheritance or inheritance.
             
  According to GOF, bridging mode and adapter mode are used in different stages of design, and bridging mode is used in the early stage of design, that is, when designing a class, the class is planned into two major classes, logic and implementation, so that they can evolve separately; The adapter pattern is used after the design is completed, and the adapter pattern can be used when it is found that the designed classes cannot work together.
  However, in many cases the use of the adapter pattern should be considered early in the design, such as when a large number of third-party application interfaces are involved.

Combination of adapter mode and bridge mode

  In practical applications, bridge mode and adapter mode often appear at the same time. This situation often occurs when other systems are required to provide implementation methods. A typical example is data acquisition in industrial control. The underlying data acquisition interfaces provided by different industrial control manufacturers are usually different, so it is impossible to predict which interfaces may be encountered when designing upper-level software. To this end, it is necessary to define a general acquisition interface, and then develop the corresponding adapter for the specific data acquisition system. Data storage needs to call the data acquisition interface to obtain data, and the data can be saved in relational database, real-time database or file. The data storage interface and the data acquisition structure form a bridge.
       
  The same structure often appears in report-related applications, and the structure of the report itself and the report output method can be completely separated. The report output can be abstracted separately from the concrete form of the report. However, the report output depends on the specific output method. If the output is in PDF format, the PDF-related API must be called, which is beyond the control of the design, so the adapter mode is used here.

The relationship between adapter mode and appearance mode

  适配器模式与外观模式有些相似,都是对现相存系统的封装。但这两种模式的意图完全不同,前者使现存系统与正在设计的系统协同工作而后者则为现存系统提供一个更为方便的访问接口。简单地说,适配器模式为事后设计,而外观模式则必须事前设计,因为系统依赖于外观。总之,适配器模式没有引入新的接口,而外观模式则定义了一个全新的接口。

  适配器模式用于粒度较小的功能集成,如使用权威单位所规定的无法修改并替换的现有算法模块(油罐的容积算法为国家计量权威单位所规定,需要使用特定的模块),将来也可能升级。这时可以使用适配器模式。

  外观模式的使用有时比较难把握,外观接口的定义与设计人员对业务的理解程度有很大关系。如果接口设计过于复杂,则不如直接调用原系统简单;如果接口设计过于简单,有些功能需要调用原有系统才能实现,同样达不到封装目的。在这种情况下,首先要考虑被封装系统的稳定程度。如果系统处于演化阶段,那么接口定义需要复杂一些,以暴露更多的接口。这时,外观模式更像一个大粒度的适配器。被封装系统发生演化时,需要新的外观对象,而这个外观对象起到了适配器的作用。下图所示为这种情况下的结构。
             
总结

  我们讨论了适配器模式、桥接模式和外观模式之间的关系。适配器模式经常用在需要与第三方API协同工作的场合,在功能集成需求越来越多的今天,这种模式的使用频度越来越高,特别是桥接模式与适配器的组合在设计中越来越频繁地出现,几乎已经成为一种新的模式。

  外观模式是另一个在系统演化中常用的模式,在某些情况下,它与适配器模式的作用有些相似。但总体上来说,外观模式所针对的对象粒度更大。

 

参考文章:适配器、桥接与外观三模式之间关系 

桥梁模式和适配器模式的区别

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=327071441&siteId=291194637