powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / Преложите архитектуру решения
18 сообщений из 18, страница 1 из 1
Преложите архитектуру решения
    #39631362
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Задача такая:

есть настройки различных общих функциональностей. Например, настройки построения графика, перебора файлов в папке, использования дисковой подсистемы и т.д. Подсистемы чаще всего используют не все функциональности: кто- то не работает с диском, кто- то не строит графика и т.д. Но есть и общие параметры, которые могут использовать разные подсистемы: наличие диспетчера задач, фильтра сообщений и т.д.

Как организовать для каждой подсистемы систему своих настроек?

Напрашивается разбиение настроек по функциональностям и множественное наследование от них в итоговые настройки. Но присутствие общих параметров губит эту идею на корню: у меня будет по несколько экземпляров общих параметров в итоговых настройках.

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

Как сделать?
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39631365
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
UPDATE:
Но есть и общие параметры, которые могут использовать разные общие функциональности : наличие диспетчера задач, фильтра сообщений и т.д.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39631373
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQL, раздели на функциональные блоки в виде статических или динамически линкуемых библиотек.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39631382
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
rdb_devAlekseySQL, раздели на функциональные блоки в виде статических или динамически линкуемых библиотек.

Так это уже сделано. Вопрос как соединить настройки функциональных блоков в общую структуру. Как получить структуру С причем унаследованную от А и В (чтобы можно было написать общий функционал):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
struct A{
int A;
int B;
};

struct B{
int B;
int C;
};

struct C: public A, public B{
int A;
int B;
int C;
};
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39631420
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQL,

1. settings["log_param1"], settings["fileview_param1"]

2. settings.log_param1, settings.fileview_param1

не надо множить сущности без надобности
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39631426
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SiemarglAlekseySQL,

1. settings["log_param1"], settings["fileview_param1"]

2. settings.log_param1, settings.fileview_param1

не надо множить сущности без надобности

Ничего не понял.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39631501
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQL,

Хранить все настройки всех компонентов в одном месте.
Каждый компонент работает со своим подмножеством этих настроек, игнорируя остальные (хотя и имея возможность к ним обращаться, если прикажет темный властелин).
Вот как выше Siemargl написал.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39631543
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLЗадача такая:

есть настройки различных общих функциональностей. Например, настройки построения графика, перебора файлов в папке, использования дисковой подсистемы и т.д. Подсистемы чаще всего используют не все функциональности: кто- то не работает с диском, кто- то не строит графика и т.д. Но есть и общие параметры, которые могут использовать разные подсистемы: наличие диспетчера задач, фильтра сообщений и т.д.

Как организовать для каждой подсистемы систему своих настроек?

Напрашивается разбиение настроек по функциональностям и множественное наследование от них в итоговые настройки. Но присутствие общих параметров губит эту идею на корню: у меня будет по несколько экземпляров общих параметров в итоговых настройках.

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

Как сделать?

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

Люди тратят на эту хрень тонны времени и пишут тонны кода, когда это всё не нужно.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39631552
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLСоздавать класс для каждого параметра и выполнять виртуальное множественное наследование- очень громоздко и к тому же бизнес- логика переносится на код наследования (поскольку надо знать какие параметры нужны для той или иной общей функциональности), а не инкапсулирована в файлах с описанием общей функциональности.



Наследование -- очень плохо IMHO применять для настроек.
Применяй просто гибкие структуры данных (типа JSON,XML etc). Т.е. структуры, которым наплевать, что внутри. Что положил -- сохранится. Не положил -- значит, сам должен знать, как настраивать.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39631569
Фотография CEMb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQL,

заведи под каждую общую настройку отдельный класс. Экземпляр этого класса храни в каком-нибудь общедоступном объекте, типа app. У app заведи методы, которые умеют возвращать ссылку на объекты. Сами классы настроек должны уметь сериализоваться, поэтому скорее всего будут отнаследованы от общего предка.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39631576
Фотография CEMb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivПрименяй просто гибкие структуры данных (типа JSON,XML etc).по-моему, он не про это, а про общие подсистемы настроек. Типа настроек графики, которые состоят из нескольких атомарных настроек, но сами всегда вместе лежат и используются.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39632020
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
CEMb, да мне не надо хранить на диске, динамически сформировать и работать.

А есть map с возможностью хранить значения произвольных типов?
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39632198
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
AlekseySQLА есть map с возможностью хранить значения произвольных типов?

Нашел, что в С++17 появился типобезопасный контейнер std::any. На хабре есть пример. Попробую его прикрутить к map.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39632469
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLCEMb, да мне не надо хранить на диске, динамически сформировать и работать.

А есть map с возможностью хранить значения произвольных типов?

boost::property_tree кажется.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39632471
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLAlekseySQLА есть map с возможностью хранить значения произвольных типов?

Нашел, что в С++17 появился типобезопасный контейнер std::any. На хабре есть пример. Попробую его прикрутить к map.

и std::variant
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39632552
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZivboost::property_tree кажется.

Стараюсь использовать только классику :)

MasterZivи std::variant

Тут надо заранее определить типы возможных значений, что не подходит для общих настроек, которые могут расширяться количественно и как следствие расширять набор возможных типов.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39633445
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQL, почитай про Convention Over Configuration. Это не фреймворк а скорее подход или принцип.
Возможно поможет.

Вообще, есть такие вещи которые тебе никто не сделает лучше чем ты сам. Конфигурация и мониторинг
твоего проекта - это никогда не шаблон. Это всегда кастомизация. Как там где лучше - ты сам себе расскажешь.
...
Рейтинг: 0 / 0
Преложите архитектуру решения
    #39633479
Фотография CEMb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLСтараюсь использовать только классику :)со временем boost перекочёвывает в std
...
Рейтинг: 0 / 0
18 сообщений из 18, страница 1 из 1
Форумы / C++ [игнор отключен] [закрыт для гостей] / Преложите архитектуру решения
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]