Прошу прощения за кросс постинг , но к сожалению по моей просьбе тему не перенесли. Я полагал что она превратиться в священную войну и сразу запостил в тот раздел. На удивление много постов было по существу и я предлагаю обсудить тему тут, в Архитектуре.

//==============================================================================================================================================================================

Как большой любитель шаблона Singleton, хочу поговорить про использование этого шаблона для логирования. Логирование часто приводится как пример умесного применения сингелтона.

Исторически сложилось что сингелтон от GOF это две ответственности в одном классе, ах нет три как минимум , еще есть функциональность сингелтона. Я попробую выполнить функциональную декомпозицию.

Modern Singelton = Single instance (data) + Global Enrty Point + class functionality.

Насколько это замечательно ? давайте помоделируем поведение логера.

1. Я исхожу из предпосылки что доступ к логеру довольно удобен через глобальную точку входа.


Итак делаем логер через сингелтон! Logger->GetInstance();

Все супер кроме небольшого недостатка, недетерминированное время создание + недетерминированное время жизни. В общем случае это недостаток , так как от порядка создания может меняться поведение программы. Банальный пример , логирование в файл когда нет места на диске , создание сингелтона падает в неожиданных местах и превносит массы приятных сюрпризов.


2. Соседний отдел потребовал чтобы логер для их модуля отправлял по сети некие отладочные данные. У нас с этим проблем нету, сделали. Теперь сингелтон пишет в файл и кидает по сети.

3. Еще один отдел потребовал чтобы все варнинги писались в системный лог ошибок. Без проблем сделали.

4. Обнаружили что более 10 модулей в штатном режиме создают ТАКОЙ поток варнингов что от системного лога остается только пух и прах. На этом этапе приходится много думать. Появляется большое к-во полумер, но в итоге приходит решение , выставить для этого модуля некий флажок состояния в логере. Logger->SetEnableSys(true) и затем после отработки модуля опять в фолс.

5. Отдел супер спецов утверждает что они хотят пользоваться своей имплементацией логера , которая позволит провести какие то тесты. После продолжительного бодания вы пишете сервисную функцию Logger->SetInstance(ILogger* );

6. оглядываемся и видим что у нас осталось

Our Singelton = Global Enrty Point + class functionality. Вы видим что оснавная функция сингелтона , обеспечение единсвенности экземпляра класса ПОТЕРЯНА. Мы видим что реально нам нужна была только Global Enrty Point. Помедитировав над этим вопросом оставляем только Global Enrty Point + class functionality. При этом на верхнем уровне предоставляем интерфейс для управлениями различными инстансами логеров.

В итоге получаем Детерминированное создание и уничтожение классов сингелтонов, которые могут быть подключены/отключены во время выполнения. Каждый моджуль может контролировать и использовать логирование как ему будет удобно , в рантайме.

7. После непродолжительного бодания с Logger->GetInstance(); или ServiceProvider->GetLogger() и.т.п Мы понимаем что все что нам нужно от логера это глобальная точка входа , в идеале типизированная.

Конечным вариантом появляется или глобальная ф-ция Logger::Log(...) или LogService::GetLog().


Выводы:

Не путайте Singelton и Global Enrty Point . Это разные сущности и решают перпендикулярные задачи.

Спасибо за внимание.