Так это частая модель у событийных шин: есть простая подписка на событие, а есть единоразовое выполнение, чтобы обработчику самому не нужно было отписываться
Так это частая модель у событийных шин: есть простая подписка на событие, а есть единоразовое выполнение, чтобы обработчику самому не нужно было отписываться
Тут прикол в том, что SQLite - единственный способ хранить временные или постоянные данные. Поэтому провайдер тут может знать о SQLite, т.к. это его непосредственная реализация (в плане, что он является обёрткой для драйвера). Ну и варианты тоже хранения тоже объявлены через два раздельных констурктора:
без аргументов: in-memory для временных данных
с путём файла: персистивное хранение, чтобы после перезапуска данные остались
Тут прикол в том, что SQLite - единственный способ хранить временные или постоянные данные. Поэтому провайдер тут может знать о SQLite, т.к. это его непосредственная реализация (в плане, что он является обёрткой для драйвера). Ну и варианты тоже хранения тоже объявлены через два раздельных констурктора:
- без аргументов: in-memory для временных данных
- с путём файла: персистивное хранение, чтобы после перезапуска данные остались
Я вот думаю над тем, как правильнее реализовать. Конкретно этот класс - это интерфейс публичного API от движка к модулям. И пока архитектура у движка такая: движок реализует событийную шину и что-то типа фабрики БД-провайдеров, а всё остальное реализуется только модулями, которые подключаются в движок при его конструкте.
Пока не вижу идеи, как лучше сделать ;(
Я вот думаю над тем, как правильнее реализовать. Конкретно этот класс - это интерфейс публичного API от движка к модулям. И пока архитектура у движка такая: движок реализует событийную шину и что-то типа фабрики БД-провайдеров, а всё остальное реализуется только модулями, которые подключаются в движок при его конструкте.
Пока не вижу идеи, как лучше сделать ;(
Да, я равновато onInitialize запихнул, потому что жизненный цикл буду делать в следующей ветке. Пока чисто положил его сюда, чтобы изучить сборку интерфейсов на плюсах))
Да, я равновато `onInitialize` запихнул, потому что жизненный цикл буду делать в следующей ветке. Пока чисто положил его сюда, чтобы изучить сборку интерфейсов на плюсах))
В целом, не обязательно писать буквами каждый раз, потому что можно бахнуть enum, который будет хранить строчки и просто использовать варианты enum'а, чтобы подавать
В целом, не обязательно писать буквами каждый раз, потому что можно бахнуть enum, который будет хранить строчки и просто использовать варианты enum'а, чтобы подавать
В целом неплохо, но полный жизненный цикл пока не реализован, CMake чисто чтоб заработало.
В остальном есть по коду мелкие замечания, но думаю, это проблемы первой версии реализации.
В целом неплохо, но полный жизненный цикл пока не реализован, CMake чисто чтоб заработало.
В остальном есть по коду мелкие замечания, но думаю, это проблемы первой версии реализации.
Dmitriy
merged commit a6676997d4 into master2026-09-29 14:25:08 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Dmitriy
Реализовано:
@@ -0,0 +56,4 @@/// @brief Subscribe to specified event and execute once on publish/// @param name event name/// @param listener event handlerSubscriptionId subscribeOnce(const std::string &name, Listener listener);воняет писями. где subcribe1 subcribe2 subcribe3 subcribeFinal subcribeFinalFinal??
Так это частая модель у событийных шин: есть простая подписка на событие, а есть единоразовое выполнение, чтобы обработчику самому не нужно было отписываться
@@ -0,0 +5,4 @@{}MscEngineDBProvider::MscEngineDBProvider(const std::string &filepath)только sqlLite? типа провайдер получает путь к файлу
Тут прикол в том, что SQLite - единственный способ хранить временные или постоянные данные. Поэтому провайдер тут может знать о SQLite, т.к. это его непосредственная реализация (в плане, что он является обёрткой для драйвера). Ну и варианты тоже хранения тоже объявлены через два раздельных констурктора:
@@ -7,2 +13,4 @@class IMscEngineModuleAPI{public:virtual ~IMscEngineModuleAPI() = default;не слишком ли много ответственности для этого молодого человека? чет он дохера чего в себе делает и чувствую бесконечность не предел.
Я вот думаю над тем, как правильнее реализовать. Конкретно этот класс - это интерфейс публичного API от движка к модулям. И пока архитектура у движка такая: движок реализует событийную шину и что-то типа фабрики БД-провайдеров, а всё остальное реализуется только модулями, которые подключаются в движок при его конструкте.
Пока не вижу идеи, как лучше сделать ;(
@@ -23,3 +25,3 @@/// Module initialization phasevirtual void onInitialize();virtual void onInitialize(IMscEngineModuleAPI &engine) = 0;не описан порядок вызова onInitialize
Да, я равновато
onInitializeзапихнул, потому что жизненный цикл буду делать в следующей ветке. Пока чисто положил его сюда, чтобы изучить сборку интерфейсов на плюсах))@@ -0,0 +15,4 @@virtual ~MscEvent() = default;/// @brief Get event namevirtual std::string getName() const = 0;Берем по имени листенеры? очепятка и все пошло по пизде
В целом, не обязательно писать буквами каждый раз, потому что можно бахнуть enum, который будет хранить строчки и просто использовать варианты enum'а, чтобы подавать
В целом неплохо, но полный жизненный цикл пока не реализован, CMake чисто чтоб заработало.
В остальном есть по коду мелкие замечания, но думаю, это проблемы первой версии реализации.