【设计模式】封装器模式:适配器模式

意图

适配器模式能使接口不兼容的对象能够相互合作。
【设计模式】封装器模式:适配器模式

问题

假如你正在使用 C++ 开发一个程序,在开发过程中需要使用一系列用 C 语言编写的函数,需要将一个类传入到这些函数中。而 C 语言是不支持类这一概念的,C 语言实现类,只能通过用结构体模拟类。
为了用户的使用体验,你还是希望用户使用的是C++中的类,而不是使用结构体模拟出来的类。但是如果将那一系列 C 函数重新用 C++ 实现一遍,工作量就会非常大。
【设计模式】封装器模式:适配器模式

解决方案

你可以创建一个适配器,这是一个特殊的对象,能够转换对象接口,使其能与其他对象进行交互。适配器模式通过封装对象将复杂的转换过程隐藏于幕后,被封装的对象甚至察觉不到适配器的存在。
在刚才的问题中就可以如下图,在类和 C 函数中间加一个适配器,通过转换函数,将类转换成结构体。由于适配器继承自结构体,所以可以将适配器作为结构体直接传入 C 函数中。而需要调用结构体方法时,则通过 m_class 这个成员变量访问类的函数。
【设计模式】封装器模式:适配器模式

示例代码

以下是 AWTK-MVVM 使用适配器的部分示例代码:

/* temperature_validator.cpp */
#include "temperature_validator.hpp"
#include "mvvm/cpp/adapter.hpp"

class TemperatureValidator : public vm::ValueValidator {
 public:
  virtual bool_t IsValid(const value_t* value, str_t* msg) {
    int32_t temp = value_int(value);

    if (temp <= 20) {
      str_set(msg, "too low");
      return FALSE;
    } else if (temp >= 60) {
      str_set(msg, "too high");
      return FALSE;
    } else {
      str_set(msg, "normal");
      return TRUE;
    }
  }

  virtual ret_t Fix(value_t* value) {
    return RET_OK;
  }
};

static void* create_water_temp_validator(void) {
  /* class 转换为 struct */
  return vm::To(new TemperatureValidator());
}

ret_t temperature_validator_init(void) {
  value_validator_register("water_temp", create_water_temp_validator);

  return RET_OK;
}
/* value_validator.c */
/* C函数 */
ret_t value_validator_register(const char* name, tk_create_t create) {
  return_value_if_fail(name != NULL, RET_BAD_PARAMS);
  return_value_if_fail(create != NULL && s_validator_factory != NULL, RET_BAD_PARAMS);

  return object_set_prop_pointer(s_validator_factory->creators, name, create);
}
/* value_validator.h */
/**
 * @class value_validator_t
 * @parent object_t
 *
 * 值校验器。
 *
 * 用户在界面上输入的类型可能是无效的,value_validator负责将检查用户输入的有效性。
 *
 */
struct _value_validator_t {
  object_t object;

  object_t* context;

  /*private*/
  value_validator_is_valid_t is_valid;
  value_validator_fix_t fix;
}value_validator_t;
/* adapter.cpp */
namespace vm {
static object_vtable_t s_value_validator_adapter_vtable;

typedef struct _value_validator_adapter_t {
  /* 继承: value_validator_adapter_t -> value_validator_t -> object_t */
  value_validator_t value_validator;

  /*private*/
  ValueValidator* cpp;
} value_validator_adapter_t;

static ret_t value_validator_adapter_init_vtable(object_vtable_t* vt) {
  vt->type = "value_validator_adapter";
  vt->desc = "value_validator_adapter";
  vt->size = sizeof(value_validator_adapter_t);
  vt->is_collection = FALSE;

  return RET_OK;
}

#define VALUE_VALIDATOR_ADAPTER(obj) ((value_validator_adapter_t*)(obj))

static bool_t value_validator_adapter_is_valid(value_validator_t* c, const value_t* value,
                                               str_t* msg) {
  value_validator_adapter_t* value_convert_adapter = VALUE_VALIDATOR_ADAPTER(c);

  /* 调用 class 函数 */
  return value_convert_adapter->cpp->IsValid(value, msg);
}

static ret_t value_validator_adapter_fix(value_validator_t* c, value_t* value) {
  value_validator_adapter_t* value_convert_adapter = VALUE_VALIDATOR_ADAPTER(c);

  return value_convert_adapter->cpp->Fix(value);
}

value_validator_t* value_validator_cpp_create(ValueValidator* cpp) {
  object_t* obj = NULL;
  value_validator_t* value_convert = NULL;
  return_value_if_fail(cpp != NULL, NULL);
  value_validator_adapter_t* value_convert_adapter = NULL;

  value_validator_adapter_init_vtable(&s_value_validator_adapter_vtable);
  obj = object_create(&s_value_validator_adapter_vtable);
  return_value_if_fail(obj != NULL, NULL);

  value_convert = VALUE_VALIDATOR(obj);
  value_convert->fix = value_validator_adapter_fix;
  value_convert->is_valid = value_validator_adapter_is_valid;

  value_convert_adapter = VALUE_VALIDATOR_ADAPTER(obj);
  value_convert_adapter->cpp = cpp;

  return value_convert;
}

value_validator_t* To(ValueValidator* cpp) {
  return value_validator_cpp_create(cpp);
}
}  // namespace vm

适配器模式结构

对象适配器

使用了构成原则: 适配器实现了其中一个对象的接口, 并对另一个对象进行封装。
上述示例代码用的就是对象适配器。

特点

  • 当 Service 类较为复杂时,构造一个 Service 类对象比较困难。
  • 在 Service 类新增抽象方法,Adapter 类无需修改,也能正常使用。
  • 可以使用多态的方式在 Adapter 类中调用 Service 子类的方法。
    【设计模式】封装器模式:适配器模式

类适配器

使用了继承机制: 适配器同时继承两个对象的接口。
特点

  • Adapter 类直接继承 Service 类,可以在 Adapter 类中对 Service 类的方法进行重定义。
  • 在 Service 类新增抽象方法,Adapter 类也要改动,代码耦合度高。
  • 如果 Service 类有其他子类,Adapter 类中无法调用 Service 子类的方法。【设计模式】封装器模式:适配器模式

总结

适配器模式结构选择

尽量使用耦合度比较低的对象适配器,少使用类适配器,避免多重继承。但如果构造 Service 对象非常困难时,可以考虑使用类适配器。

适合应用场景

  • 当你希望使用某个类, 但是其接口与其他代码不兼容时, 可以使用适配器类。
  • 如果需要复用这样一些类, 他们处于同一个继承体系, 并且他们又有了额外的一些共同的方法,
    但是这些共同的方法不是所有在这一继承体系中的子类所具有的共性。
    【设计模式】封装器模式:适配器模式

优点

  • 开闭原则,只要客户端代码通过客户端接口与适配器进行交互,你就能在不修改现有客户端代码的情况下在程序中添加新类型的适配器。
  • 单一职责原则,将接口或数据转换代码从程序主要业务逻辑中分离。

缺点

  • 代码整体复杂度增加,因为你需要新增一系列接口和类。有时直接更改服务类使其与其他代码兼容会更简单。

参考

22种设计模式:refactoringguru.cn/design-patterns
AWTK:github.com/zlgopen/awtk
《设计模式:可复用面向对象软件的基础》

上一篇:async-validator 表单验证两种数据的解决方案


下一篇:Hibernate Validator异常HV000221解决办法