Проблемы заключается в следующем:Полиморфного Перевод/Дизайн Преобразования данных шаблон
рассмотрит следующий класс
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&);
Так мы избегаем загрязнения производных классов по стоимости решения «менее ОО» и, возможно, способность выполнять эти операции по переводу в массе.
Это также имеет больший смысл, если мы рассмотрим возможность поддержки многих представлений, отличных от any_map, например.
using boost::ptree;
using json_class;
using xml_class;
Но еще раз, это не полиморфно.
Большинство шаблонов проектирования «перевода», которые я прочитал о сделке с интерфейсами, но я не нашел тот, который формально обращается к переводу/преобразованию данных в контексте полиморфизма.
Я ищу ссылку на шаблон дизайна, который формально решает эту проблему, советы о том, как продолжить реализацию и/или указывать на явные изъяны в моем подходе.
Вы, вероятно, хотите, чтобы объяснить, почему сериализации (например, повышение :: Сериализация) не работает для вас. –
* «Итак, мы избегаем загрязнения производных классов» * ... песок на пляже? * "также имеет гораздо больший смысл, если мы рассмотрим" * ... не так ли? Какое количество представлений связано с выбором полиморфного доступа к функциям перевода? Во всяком случае, я предлагаю вам использовать *** *** шаблон *** (через виртуальную диспетчеризацию для производных типов), с разными посетителями для каждого формата, с которым вы имеете дело: таким образом вы реализуете посетителя один раз за каждый класс, основанный на базе base_data , и его можно преобразовать в/из любого числа форматов. –
н.м. не уверен, что я понимаю, как boost :: serialization решает что угодно. Я не эксперт в библиотеке, но насколько я понимаю, это обеспечивает худшее из обоих решений - изменение производных классов и отсутствие полиморфного поведения. Я мог ошибаться в последнем, но в любом случае это только один тип представления, который не обязательно является одним (или единственным), который мне понадобится. –