C ++ Дизайн Entity & Manager Абстракция

Question

Я работаю над кодом для работы с набором событий.Эти события могут сохраняться по-разному, в зависимости от их конкретного типа.В настоящее время у меня есть интерфейс iEvent, абстрагирующий события, интерфейс iBackend для каждого из способов их сохранения и набор небольших интерфейсов (iFileEvent, iDBEvent и т. Д.) Для каждого бэкенда, который определяет методы преобразования в представление сериализации, требуемое изсамо событие.Каждый конкретный класс событий реализует iEvent и любую поддерживаемую им комбинацию интерфейсов возможностей.

Все это прекрасно работает при десериализации, так как это выполняется реализациями бэкэнда (file, db и т. Д.), Поэтому они знают, что конкретнотипы событий, создаваемые из их существующего содержимого, и, следовательно, могут использовать открытые методы конкретного класса событий для их созданияОднако сейчас я нахожусь в точке, где мне нужно сериализовать новые события, и у меня возникло небольшое затруднение.

Проблема в том, что я не предоставляю конкретный тип для каждого бэкэнда, поскольку они получают только данныеiEvent из-за интерфейса iBackend.

Я могу добавить динамический_каст или просто использовать сравнение RTT (или его более дешевую версию) и static_cast, но я не уверен, что есть лучшийметод для запроса возможностей, и я не вижу ясного способа решить эту проблему ни с одним из этих предложений.

Мой конкретный случай желания преобразований между конкретным типом события и структурами данных, использованными для их сохранения вкаждый бэкэнд может быть реализован набором методов в бэкенде для каждого типа события, но мне это совсем не нравится ... но набор декораторов преобразования для каждой комбинации класса и бэкенда пахнет как неприятный случайтакже взрыв классов.

Кажется бессмысленным добавлять классы, когда все, что мне нужно, это классы событий, чтобы заявить, что ониподдерживать интерфейс для каждого бэкэнда ... что заставляет меня думать, что варианты приведения являются единственным способом продвижения вперед.

Итак, в общем, я ищу совет по лучшим решениям для этого.

Answer 1

Вот какое-то решение:

1. сохранить взрыв {file, db} * {Event1, Event2}
2. , но вместо создания отдельного класса для каждой комбинации, попробуйте построитьклассы, которые работают более чем для одной комбинации.

3. Тогда ваш код просто перечисляет все комбинации, но создает следующие виды структур для каждой комбинации:

   struct Comb1 {File f;Event1 e;Impl1 i1;};

   struct Comb2 {Db d;Событие 1 е2;Impl2 i3;};

   struct Comb3 {Файл f;Event2 e;Impl1 i1;};

   struct Comb4 {Db d;Event2 e;Impl3 i1;};

Они просто выбирают правильную реализацию в использовании.

Затем строят базовые классы для всех классов:

struct Generic { FileDbBase *ptr; EventBase *base; ImplBase *impl; };

Затем создайте 2d массивуниверсального, проиндексированного как {file, db}, так и {Event1, Event2}.Эта структура позволяет вам повторно использовать существующие реализации.Добавьте экземпляры Comb1, Comb2, Comb3, Comb4 в массив 2D.