G
странная архитектура у тебя реально
Size: a a a
2020 August 16
RM
Короче, нужно ООП, где от HFModule унаследуется класс, а от него множество классов, но при этом, это множество классов не являются создателями того класса, который унаследовался от HFModule
RM
Щас скину картинку
G
ну реально оверинжиниринг во все поля
G
модуль - это множество плагинов? так ебани using Module = std::vector<Plugin&> и все
G
про бритву Оккама слыхал?
A
вотебан за читы кстати
Вообще да, заебал этот чувак со своей читовой херней, спермотоксикозом, незаслуженным поливом грязью норм либ для работы со списками процессов
A
Мне нужно было решить геморрой архитектуры, когда два инклюда друг друга хотели поиметь
Надо третий делать тогда
A
Нужно как то обезопасить разрабов еще чем то помимо доксигена, что GetPlugin на указателях других модулей не вызывать
private:
RM
Вот что-то вроде этого надо
A
Еще нуждаюсь в совете, не знаю как лучше архитектурно реализовать возможность плагинов получать указатели на сторонние модули. В голову пришла только одна хорошая идея, это в списке инициализации вызывать
this->GetModule()->GetApp()->GetModule<Type>Как в унити: GetComponent<T>()
A
protected возьми
RM
Только ModuleTest не создается благодаря PluginA/B/C, ModuleTest класс создается сам по себе, но хранит внутри себя PluginA/B/C объекты
A
Тогда виртуальное говно юзером не сможет вызваться
RM
protected возьми
виртуальное говно от HFModule?
G
а базовый класс типа HFPlugin есть?
G
я запутался
RM
а базовый класс типа HFPlugin есть?
а кстати, спасибо что напомнил
RM
Есть пару открытых вопросов