问题如下:
考虑以下课程
class data : public base_data
{
public:
int a;
std::string b;
double c;
... // many other members
};
假设公开这个类的数据成员是完全有意义的。
现在考虑有很多这样的类,每个都有不同的成员,可能都派生自同一个基类“base_data”。
现在,这些类需要从其他任意数据表示中导出、导入、构造、“设置”和“获取”。
例如:
using any_map = boost::unordered_map < std::string, boost::any > ;
就是这样一种表示。
此外,所有这些操作都需要大量完成,即通过 base_data* 对象的集合以多态方式完成。
此问题的一种解决方案是在 base_data 中提供一个接口,如下所示
class base_data
{
public:
virtual void set(const any_map&) = 0;
virtual any_map get() const = 0;
};
每个派生类都知道它的成员,因此它知道如何进行翻译。另外派生类可以提供以下形式的构造函数
data(const any_map&) {...}
允许轻松定义抽象工厂模式。
这个问题的另一个解决方案是在某些命名空间下为每个派生类型提供静态翻译函数,例如
static data convert(const any_map&);
static any_map convert(const data&);
因此,我们以“更少的 OO”解决方案和可能大规模执行这些翻译操作的能力为代价避免了派生类的污染。
如果我们考虑需要支持除 any_map 之外的许多表示的可能性,这也更有意义,例如
using boost::ptree;
using json_class;
using xml_class;
但再一次,它不是多态的。
我读过的大多数“翻译”设计模式都处理接口,但我还没有找到一种正式解决多态性上下文中数据的翻译/转换的模式。
我正在寻找对正式解决此问题的设计模式的参考,关于如何继续实施的建议和/或指出我的方法中明显的缺陷。