История изменений

Мне просто нужен простой лог который умеет переключаться между выводом в файл и в терминал. Накой черт мне твой огород городить?

Я ж говорю, что с решение с логгером-синглтоном — спорное, а не непригодное.

Мне в каждом модуле предлагаешь считывать/парсить/кэшировать/автоматически бекапить настройки программы?

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

Или в каждый класс передавать экземпляр объекта Settings?

Да. В конструктор и (если надо) в OnSettingsChanged().

И еще, есть вот у меня БД с кэшем в RAM. Кэш для клиентов общий и единственно существующий - почему мне не вытащить его в Singleton?

Потому что каждый клиент должен работать со своим торчком от «бд». Тот факт, что торчок под капотом проверяет общий RAM-кэш и лезет в общую БД --- лежит вне компетенции клиентов. Сегодня логика кэширования и работы с БД одна, а завтра по каким-то причинам может стать совсем другая. Может быть принято решение разным клиентам разный объем RAM каким-то образом предоставлять, разное время жизни кэшированных объектов в RAM сделать, и тому подобное. Чем меньше клиенты обо всей этой кухне знают, тем легче будет внести изменения.

Мне просто нужен простой лог который умеет переключаться между выводом в файл и в терминал. Накой черт мне твой огород городить?

Я ж говорю, что с решение с логгером-синглтоном — спорное, а не непригодное.

Мне в каждом модуле предлагаешь считывать/парсить/кэшировать/автоматически бекапить настройки программы?

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

Или в каждый класс передавать экземпляр объекта Settings?

Да. В конструктор и (если надо) в OnSettingsChanged().

И еще, есть вот у меня БД с кэшем в RAM. Кэш для клиентов общий и единственно существующий - почему мне не вытащить его в Singleton?

Потому что каждый клиент должен работать со своим торчком от «бд». Тот факт, что торчок под капотом проверяет общий RAM-кэш и лезет в общую БД --- лежит вне компетенции клиентов. Сегодня логика кэширования и работы с БД одна, а завтра по каким-то причинам может стать совсем другая. Может быть принято решение разным клиентам разный объем RAM каким-то образом предоставлять, разно время жизни кэшированных объектов в RAM сделать, и тому подобное. Чем меньше клиенты обо всей этой кухне знают, тем легче будет внести изменения.

Мне просто нужен простой лог который умеет переключаться между выводом в файл и в терминал. Накой черт мне твой огород городить?

Я ж говорю, что с решение с логгером-синглтоном — спорное, а не непригодное.

Мне в каждом модуле предлагаешь считывать/парсить/кэшировать/автоматически бекапить настройки программы?

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

Или в каждый класс передавать экземпляр объекта Settings?

Да. В конструктор и (если надо) в OnSettingsChanged().

И еще, есть вот у меня БД с кэшем в RAM. Кэш для клиентов общий и единственно существующий - почему мне не вытащить его в Singleton?

Потому что каждый клиент должен работать со своим торчком от «бд». Тот факт, что торчок под капотом проверяет общий RAM-кэш и лезет в общую БД --- лежит вне компетенции клиентов. Сегодня логика кэширования и работы с БД одна, а завтра по каким-то причинам может стать совсем другая. Может быть принято решение разным клиентам разный объем RAM каким-то образом предоставлять, разно время жизни кэшированных объектов в RAM сделать, и тому подобное. Чем меньше клиенты обо всей этой кухне знают, тем легче будет внести изменения.