i^m currenty ищет хороший дизайн OO для сериализации приложения C++/Qt.
Представьте, что классы приложения организованы на основе древовидной структуры, реализованной с помощью Composite-Pattern, как на следующем рисунке.Хороший дизайн для сериализации C++
два возможных принципа я думал:
1.)
Поместите функцию сохранения()/нагрузки() в каждом классе, который должен быть сериализации. Если вы видели это много раз, обычно выполняются с помощью boost. Где-то в классе вы найдете что-то вроде этого:
friend class boost::serialization::access;
template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
ar & m_meber1;
}
Вы также можете отделить это в экономии() и нагрузки(). Но недостатком такого подхода является:
Если вы хотите изменить сериализацию через два месяца (в XML, HTML или что-то очень любопытное, которое не поддерживает), вы должны принять все тысячи классов. Какой, на мой взгляд, не очень хороший OO-дизайн.
И если вы хотите поддерживать разные сериализации (XML, Binary, ASCII, независимо ....) в то же время, что 80% CPP существует только для функций сериализации.
2.)
Я знаю, что повышение также обеспечивает Неинтрузивная версию сериализации
«http://www.boost.org/doc/libs/1_49_0/libs/serialization/doc/ tutorial.html»
Так еще один способ заключается в реализации итератора, который перебирает по композиционной структуре дерева и сериализующий каждый объект (и один итератор для десериализации)
(я думаю, что это то, что XmlSerializer-класс .NET-Framework делает, но я не очень хорошо знаком с .NET.)
Это звучит лучше, потому что отдельные save() и load() и только одно пятно меняются, если сериализация изменяется.
Так что это звучит лучше, НО:
- Вы должны предоставить сеттер() и getter() для каждого параметра, который вы хотите сериализовать. (Итак, частных данных нет. (Это хорошо/плохо?)
- У вас может быть длинная наследовательская иерархия (более 5 классов), висящая на составном дереве.
Итак, как вы называете setter()/getter() производных классов? Когда вы можете только вызвать функцию интерфейса базового композитного компонента.
Другой способ - сериализовать данные объектов в отдельный абстрактный формат. Из всех возможных последовательных сериализаций (XML, TEXT, независимо от того, что возможно) получают свои данные. Одна идея заключалась в сериализации ее в QDomNode. Но я думаю, что дополнительная абстракция будет стоить производительности.
Так что мой вопрос:
Кто-нибудь знает хороший OO-Design для сериализации?
Возможно, с других языков программирования, таких как JAVA, Python, C#, независимо от того, что ....
Спасибо.
Буферы протокола Google? –
Вы, кажется, путаетесь с природой _Boost.Serialization_ ... Что вы подразумеваете под «усыновлением всех тысяч классов» или «80% cpp существуют для сериализации»? Вы пишете одну единственную функцию сериализации (две, если разделены сохранение и загрузка), и используйте ее с тем, что хотите, которое поддерживает концепцию «Архивация», будь то XML, JSON, Binary, что угодно .. –
Yep, @ K-ballo is right , И подумайте, что, если через два месяца вам не придется переключать тип архива - это довольно просто, но что, если вам нужно что-то изменить в дереве и данных? Boost :: Serialization выглядит очень хорошо. – Forgottn