Каков наилучший способ разработки модели персистентности для многих классов в C ++ при одновременном обеспечении соблюдения SOLID? - PullRequest
0 голосов
/ 14 мая 2018

Я искал в Интернете конкретную информацию по проектированию о том, как эффективно проектировать персистентную модель для классов C ++, и у меня не получилось.Поэтому я решил спросить это здесь.

Допустим, у меня есть 4 класса:

Класс A

Класс B

Класс C

Класс Persist

Я хочу сохранить классы A, B и C на диске, используя класс "Persist", чтобы один файл содержал информацию о конфигурации для каждого класса:

my_module.json
{
  A {
    ...
  },
  B {
    ...
  },
  C {
    ...
  }
}

Myвопрос в том, каков наилучший подход к разработке такой, чтобы следовать принципам SOLID?

Например, принцип единой ответственности предполагает, что класс должен иметь только одну ответственность (или только одну причину для изменения) и ЗаконДеметры предполагает, что классы знают как можно меньше друг о друге.

Итак:

1) Должен ли класс знать, как сериализовать себя, или это уже нарушит единственную ответственность?

2) Если я использую стороннюю библиотеку, такую ​​как "cereal", для сериализации "Class A", мне нужно будет добавить теги к внутренним членам "Class A", чтобы показать движку, как он должен сериализоваться.Это увеличивает связь между «Классом А» и сторонним движком, что должно быть плохо, верно?

3) Должен ли я вместо этого использовать промежуточные классы, которые переводят объект из «Класса А» в объект с соответствующими тегамичто сторонняя библиотека поймет?Это устраняет любые знания о сериализации из «Класса А», но добавляет больше сложности и больше классов.

4) Должен ли класс знать о модуле постоянства?Реально ли это при попытке сериализации?Если да, то как класс должен уведомить модуль персистентности о том, что состояние изменилось и настало время для сохранения?Или модуль постоянства должен просто периодически опрашивать объекты на предмет новой конфигурации?

Я довольно новичок в ОО, но глубоко заинтересован.Особенности взаимодействия между классами будут очень полезны.Спасибо.

1 Ответ

0 голосов
/ 15 мая 2018

Обычно в разработке программного обеспечения решения принимаются не о принципах, а о компромиссах.

1 - это нарушает единственную ответственность, но в C ++ у вас нет большого выбора.Язык изначально не поддерживает отражения во время выполнения, а также виртуальные конструкторы / фабрики классов.Без этих двух функций очень сложно реализовать сериализацию объектов без сериализации самих объектов.Под «очень сложным» я подразумеваю, что для этого требуются внешние инструменты или большое количество макросов / шаблонов, IMO очень дорогая для поддержки долгосрочной поддержки.

2 - это увеличивает сцепление, добавляет много сложности (у вас будетдля поддержки любой сторонней библиотеки, которую вы используете), но если вам нужно поддерживать несколько различных форматов сериализации одновременно, например, JSON, XML и двоичные файлы, это все равно может быть полезно.

3 - зависитно я бы сказал «нет».Хороший формат для промежуточного представления - это что-то вроде дерева DOM, и вы тратите на это слишком много процессорного времени, потому что слишком много небольших выделений ОЗУ и погоня за указателями.Если по какой-либо причине вы хотите разработать и поддерживать четко определенное промежуточное представление, я бы структурировал его как пару управляемых событиями интерфейсов (один читатель, другой писатель), см. SAX для вдохновения.

4 - Большинство библиотек сериализации спроектированы таким образом, что сохранение / загрузка является одноразовым процессом.Причина этого в том, что большинство современных универсальных форматов сериализации (XML, JSON, большинство двоичных форматов) не поддерживают обновления.Вам все равно придется выписать полный файл.Уведомления приносят пользу только тогда, когда формат хранения поддерживает частичные обновления, например, если вы сохраняете / загружаете в [встроенную] базу данных, а не только в файл JSON.Обычная практика - вызывать save вручную извне, каждый раз, когда вы заканчиваете модифицировать ваши объекты.С помощью автоматического сохранения легко тратить слишком много пропускной способности ввода-вывода и процессорного времени на запись объектов в некоторых несовместимых промежуточных состояниях.

...