Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
Задача такая: есть настройки различных общих функциональностей. Например, настройки построения графика, перебора файлов в папке, использования дисковой подсистемы и т.д. Подсистемы чаще всего используют не все функциональности: кто- то не работает с диском, кто- то не строит графика и т.д. Но есть и общие параметры, которые могут использовать разные подсистемы: наличие диспетчера задач, фильтра сообщений и т.д. Как организовать для каждой подсистемы систему своих настроек? Напрашивается разбиение настроек по функциональностям и множественное наследование от них в итоговые настройки. Но присутствие общих параметров губит эту идею на корню: у меня будет по несколько экземпляров общих параметров в итоговых настройках. Создавать класс для каждого параметра и выполнять виртуальное множественное наследование- очень громоздко и к тому же бизнес- логика переносится на код наследования (поскольку надо знать какие параметры нужны для той или иной общей функциональности), а не инкапсулирована в файлах с описанием общей функциональности. Как сделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 10:31 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
UPDATE: Но есть и общие параметры, которые могут использовать разные общие функциональности : наличие диспетчера задач, фильтра сообщений и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 10:33 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
AlekseySQL, раздели на функциональные блоки в виде статических или динамически линкуемых библиотек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 10:46 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
rdb_devAlekseySQL, раздели на функциональные блоки в виде статических или динамически линкуемых библиотек. Так это уже сделано. Вопрос как соединить настройки функциональных блоков в общую структуру. Как получить структуру С причем унаследованную от А и В (чтобы можно было написать общий функционал): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 10:57 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
AlekseySQL, 1. settings["log_param1"], settings["fileview_param1"] 2. settings.log_param1, settings.fileview_param1 не надо множить сущности без надобности ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 11:41 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
SiemarglAlekseySQL, 1. settings["log_param1"], settings["fileview_param1"] 2. settings.log_param1, settings.fileview_param1 не надо множить сущности без надобности Ничего не понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 11:46 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
AlekseySQL, Хранить все настройки всех компонентов в одном месте. Каждый компонент работает со своим подмножеством этих настроек, игнорируя остальные (хотя и имея возможность к ним обращаться, если прикажет темный властелин). Вот как выше Siemargl написал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 12:46 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
AlekseySQLЗадача такая: есть настройки различных общих функциональностей. Например, настройки построения графика, перебора файлов в папке, использования дисковой подсистемы и т.д. Подсистемы чаще всего используют не все функциональности: кто- то не работает с диском, кто- то не строит графика и т.д. Но есть и общие параметры, которые могут использовать разные подсистемы: наличие диспетчера задач, фильтра сообщений и т.д. Как организовать для каждой подсистемы систему своих настроек? Напрашивается разбиение настроек по функциональностям и множественное наследование от них в итоговые настройки. Но присутствие общих параметров губит эту идею на корню: у меня будет по несколько экземпляров общих параметров в итоговых настройках. Создавать класс для каждого параметра и выполнять виртуальное множественное наследование- очень громоздко и к тому же бизнес- логика переносится на код наследования (поскольку надо знать какие параметры нужны для той или иной общей функциональности), а не инкапсулирована в файлах с описанием общей функциональности. Как сделать? Такое говно даже архитектуры не стоит. Настройка получается по уникальному имени. Нет настройки -- применяется дефолтное значение, указанное в коде. Настройки сохраняются как пары "имя-значение" либо как JSON (почти имя значение). Люди тратят на эту хрень тонны времени и пишут тонны кода, когда это всё не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 13:21 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
AlekseySQLСоздавать класс для каждого параметра и выполнять виртуальное множественное наследование- очень громоздко и к тому же бизнес- логика переносится на код наследования (поскольку надо знать какие параметры нужны для той или иной общей функциональности), а не инкапсулирована в файлах с описанием общей функциональности. Наследование -- очень плохо IMHO применять для настроек. Применяй просто гибкие структуры данных (типа JSON,XML etc). Т.е. структуры, которым наплевать, что внутри. Что положил -- сохранится. Не положил -- значит, сам должен знать, как настраивать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 13:24 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
AlekseySQL, заведи под каждую общую настройку отдельный класс. Экземпляр этого класса храни в каком-нибудь общедоступном объекте, типа app. У app заведи методы, которые умеют возвращать ссылку на объекты. Сами классы настроек должны уметь сериализоваться, поэтому скорее всего будут отнаследованы от общего предка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 13:33 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
MasterZivПрименяй просто гибкие структуры данных (типа JSON,XML etc).по-моему, он не про это, а про общие подсистемы настроек. Типа настроек графики, которые состоят из нескольких атомарных настроек, но сами всегда вместе лежат и используются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 13:38 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
CEMb, да мне не надо хранить на диске, динамически сформировать и работать. А есть map с возможностью хранить значения произвольных типов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2018, 19:55 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
AlekseySQLА есть map с возможностью хранить значения произвольных типов? Нашел, что в С++17 появился типобезопасный контейнер std::any. На хабре есть пример. Попробую его прикрутить к map. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2018, 09:50 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
AlekseySQLCEMb, да мне не надо хранить на диске, динамически сформировать и работать. А есть map с возможностью хранить значения произвольных типов? boost::property_tree кажется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2018, 13:34 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
AlekseySQLAlekseySQLА есть map с возможностью хранить значения произвольных типов? Нашел, что в С++17 появился типобезопасный контейнер std::any. На хабре есть пример. Попробую его прикрутить к map. и std::variant ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2018, 13:35 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
MasterZivboost::property_tree кажется. Стараюсь использовать только классику :) MasterZivи std::variant Тут надо заранее определить типы возможных значений, что не подходит для общих настроек, которые могут расширяться количественно и как следствие расширять набор возможных типов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2018, 14:56 |
|
||
|
Преложите архитектуру решения
|
|||
|---|---|---|---|
|
#18+
AlekseySQL, почитай про Convention Over Configuration. Это не фреймворк а скорее подход или принцип. Возможно поможет. Вообще, есть такие вещи которые тебе никто не сделает лучше чем ты сам. Конфигурация и мониторинг твоего проекта - это никогда не шаблон. Это всегда кастомизация. Как там где лучше - ты сам себе расскажешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2018, 23:02 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=39633479&tid=2017881]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
57ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 273ms |
| total: | 424ms |

| 0 / 0 |
