Прошу прощения за кросс постинг , но к сожалению по моей просьбе тему не перенесли. Я полагал что она превратиться в священную войну и сразу запостил в тот раздел. На удивление много постов было по существу и я предлагаю обсудить тему тут, в Архитектуре.
Как большой любитель шаблона 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 . Это разные сущности и решают перпендикулярные задачи.
Здравствуйте, minorlogic, Вы писали:
M>Выводы: M>Не путайте Singelton и Global Enrty Point . Это разные сущности и решают перпендикулярные задачи. M>Спасибо за внимание.
Выводы:
Я себе не представляю даже что надо было выкурить чтобы написать метод SetInstance
Здравствуйте, adontz, Вы писали:
A>Выводы:
A>Я себе не представляю даже что надо было выкурить чтобы написать метод SetInstance
Вам интересно обсудить умственные способности выдуманных разработчиков ? Прошу приведенные мной примеры рассматривать именно как примеры привденные для наглядности , а в некоторых местах утрированные.
Здравствуйте, minorlogic, Вы писали:
A>>Я себе не представляю даже что надо было выкурить чтобы написать метод SetInstance M>Вам интересно обсудить умственные способности выдуманных разработчиков ? Прошу приведенные мной примеры рассматривать именно как примеры привденные для наглядности , а в некоторых местах утрированные.
Нет, давай я сам буду решать как и что рассматривать, ладно? Когда ты задаёшь вопрос "мы сделали так-то и так-то, получилось вот это, что скажете?" это одно. Когда ты показываешь полное непонимание предметной области (журналирование) и приводишь пример абсолютно неадекватно спроектированной системы, я оставлю за собой право спрашивать "что вы курили?" намекая не на табак. А если ещё и пафосная концовка "Выводы" присутствует, то ничего кроме улыбок такое сообщение вызвать не может.
Во-первых, журналирование настраивается не программистами. Никакого "Еще один отдел потребовал чтобы все варнинги писались в системный лог ошибок. Без проблем сделали." не бывает. Ещё один отдел правит конфигурацию, ни о каком написании кода и речи быть не может. Тем более, отдел супер спецов не предоставляет никаких альтернативных методов записи логов. Они тоже правят конфигурацию. Я больше того скажу, после выхода продукта одни админы захотят писать в syslog, другие в файл, третьи в XML-файл. Вы им что, custom build будете рассылать? Это даже не смешно.
Журналирование это способ регистрации тех или иных событий. Никогда достоверно не известно заранее когда, как и куда их регистрировать.
Далее, для клиента журналирования нет вообще никакой такой цели — иметь глобальную точку доступа. То есть этого требования вообще нет. Оно притянуто за уши и не логично. Ничегон е мешает писать (C#) new LogMessage("privet") или (С++) LogMessage("privet"). Глобальная точка доступа как таковая на самом деле вообще не нужна. Нужен именно синглтон, причём не всей системы, а только её конфигурации. И, как правило, не application-wide, а даже system-wide. Только это уже детали реализации не видные клиенту.
Вобщем, minorlogic, давайте ка вы глянете архитектуру семейства библиотек log4*, почитаете RFC 3164, ознакомитесь с проектом ULP, а уже потом мы будем что-то обсуждать. А то доказывать что чёрное это не белое желания нет совсем.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, minorlogic, Вы писали:
A>>>Я себе не представляю даже что надо было выкурить чтобы написать метод SetInstance M>>Вам интересно обсудить умственные способности выдуманных разработчиков ? Прошу приведенные мной примеры рассматривать именно как примеры привденные для наглядности , а в некоторых местах утрированные.
A>Нет, давай я сам буду решать как и что рассматривать, ладно? Когда ты задаёшь вопрос "мы сделали так-то и так-то, получилось вот это, что скажете?" это одно. Когда ты показываешь полное непонимание предметной области (журналирование) и приводишь пример абсолютно неадекватно спроектированной системы, я оставлю за собой право спрашивать "что вы курили?" намекая не на табак. А если ещё и пафосная концовка "Выводы" присутствует, то ничего кроме улыбок такое сообщение вызвать не может.
A>Во-первых, журналирование настраивается не программистами. Никакого "Еще один отдел потребовал чтобы все варнинги писались в системный лог ошибок. Без проблем сделали." не бывает. Ещё один отдел правит конфигурацию, ни о каком написании кода и речи быть не может. Тем более, отдел супер спецов не предоставляет никаких альтернативных методов записи логов. Они тоже правят конфигурацию. Я больше того скажу, после выхода продукта одни админы захотят писать в syslog, другие в файл, третьи в XML-файл. Вы им что, custom build будете рассылать? Это даже не смешно. A>Журналирование это способ регистрации тех или иных событий. Никогда достоверно не известно заранее когда, как и куда их регистрировать.
Ты просто на порядок компетентнее наших выдуманных разнаротчиков , я им передам при встрече.
A>Далее, для клиента журналирования нет вообще никакой такой цели — иметь глобальную точку доступа. То есть этого требования вообще нет. Оно притянуто за уши и не логично. Ничегон е мешает писать (C#) new LogMessage("privet") или (С++) LogMessage("privet"). Глобальная точка доступа как таковая на самом деле вообще не нужна. Нужен именно синглтон, причём не всей системы, а только её конфигурации. И, как правило, не application-wide, а даже system-wide. Только это уже детали реализации не видные клиенту.
В этом абзаце есть очень толковая мысль, что клиенту нет нужды знать о внутренних деталях реализации логирования. Но к сожалению это немного ортогонально теме обсуждения.
A>Вобщем, minorlogic, давайте ка вы глянете архитектуру семейства библиотек log4*, почитаете RFC 3164, ознакомитесь с проектом ULP, а уже потом мы будем что-то обсуждать. А то доказывать что чёрное это не белое желания нет совсем.
Спасибо, обязательно изучу если возникнет надобность.
Здравствуйте, minorlogic, Вы писали:
A>>Далее, для клиента журналирования нет вообще никакой такой цели — иметь глобальную точку доступа. То есть этого требования вообще нет. Оно притянуто за уши и не логично. Ничегон е мешает писать (C#) new LogMessage("privet") или (С++) LogMessage("privet"). Глобальная точка доступа как таковая на самом деле вообще не нужна. Нужен именно синглтон, причём не всей системы, а только её конфигурации. И, как правило, не application-wide, а даже system-wide. Только это уже детали реализации не видные клиенту.
M>В этом абзаце есть очень толковая мысль, что клиенту нет нужды знать о внутренних деталях реализации логирования. Но к сожалению это немного ортогонально теме обсуждения.
а где же комментарии насчет неортогонального (см.выделенное)
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, minorlogic, Вы писали:
R>По архитектуре протоколирования: зачем было изобретать велосипед? R>офф про велосипедостроение
Здравствуйте, minorlogic, Вы писали:
M>Я прочел что adontz у нужен для этого сингелтон. Но посколько технической аргументации я увидел , то и отвечать не на что.
Техническая аргументация по ссылкам которые я дал.
Здравствуйте, minorlogic, Вы писали:
A>>Во-первых, журналирование настраивается не программистами. Никакого "Еще один отдел потребовал чтобы все варнинги писались в системный лог ошибок. Без проблем сделали." не бывает. Ещё один отдел правит конфигурацию, ни о каком написании кода и речи быть не может. Тем более, отдел супер спецов не предоставляет никаких альтернативных методов записи логов. Они тоже правят конфигурацию. Я больше того скажу, после выхода продукта одни админы захотят писать в syslog, другие в файл, третьи в XML-файл. Вы им что, custom build будете рассылать? Это даже не смешно. A>>Журналирование это способ регистрации тех или иных событий. Никогда достоверно не известно заранее когда, как и куда их регистрировать.
M>Ты просто на порядок компетентнее наших выдуманных разнаротчиков , я им передам при встрече.
Да нет, я просто не делаю велосипеды там где не надо. А если даже прихолится, учитываю предыдущий опыт третьих лиц.
Ещё раз, апачевская log4* имеет свои недостатки, но необходимость писать код чтобы изменить метод журналирования к ним явно не относится. Настоятельно советую изучить существующие работы.
Здравствуйте, minorlogic, Вы писали:
M>Навернео потому что речь идет о сингелтонах а система логирования взята для примера , для наглядности ?
Ну, так можно любую реализацию под синглтон подвести. Но адекватной с архитектурной точки зрения она не станет.
Здравствуйте, minorlogic, Вы писали:
M>Как большой любитель шаблона Singleton, хочу поговорить про использование этого шаблона для логирования. Логирование часто приводится как пример умесного применения сингелтона.
Как большой любитель шаблона Singleton, ты наверное знаешь почему рекомендуется ограничивать видимость метода GetInstance. И что это ограничение как раз перечит задаче логирования.
M>6. оглядываемся и видим что у нас осталось M>Our Singelton = Global Enrty Point + class functionality. Вы видим что оснавная функция сингелтона , обеспечение единсвенности экземпляра класса ПОТЕРЯНА. Мы видим что реально нам нужна была только Global Enrty Point. Помедитировав над этим вопросом оставляем только Global Enrty Point + class functionality. При этом на верхнем уровне предоставляем интерфейс для управлениями различными инстансами логеров. M>В итоге получаем Детерминированное создание и уничтожение классов сингелтонов, которые могут быть подключены/отключены во время выполнения. Каждый моджуль может контролировать и использовать логирование как ему будет удобно , в рантайме. M>7. После непродолжительного бодания с Logger->GetInstance(); или ServiceProvider->GetLogger() и.т.п Мы понимаем что все что нам нужно от логера это глобальная точка входа , в идеале типизированная. M>Конечным вариантом появляется или глобальная ф-ция Logger::Log(...) или LogService::GetLog().
После ряда архитектурных ошибок допущеных в пп. 1 — 5 стало ясно, что фабрика здесь подошла бы гораздо лучше.
M>Выводы: M>Не путайте Singelton и Global Enrty Point . Это разные сущности и решают перпендикулярные задачи. Эссе в стиле "вредные советы"?
Здравствуйте, minorlogic, Вы писали:
M>Навернео потому что речь идет о сингелтонах а система логирования взята для примера , для наглядности ?
Просто намекал, к примеру, на log4j, в котором singleton вроде бы достаточно умело обходит описанные вами выше проблемы.
Здравствуйте, adontz, Вы писали:
A>Да нет, я просто не делаю велосипеды там где не надо. А если даже прихолится, учитываю предыдущий опыт третьих лиц. A>Ещё раз, апачевская log4* имеет свои недостатки, но необходимость писать код чтобы изменить метод журналирования к ним явно не относится. Настоятельно советую изучить существующие работы.
Спасибо , я им передам , надеюсь они прислушаются к твоим словам.
Здравствуйте, Blazkowicz, Вы писали:
B>Как большой любитель шаблона Singleton, ты наверное знаешь почему рекомендуется ограничивать видимость метода GetInstance. И что это ограничение как раз перечит задаче логирования.
Я не знаю "почему рекомендуется ограничивать видимость метода GetInstance" и кем и когда тоже не знаю.
B>После ряда архитектурных ошибок допущеных в пп. 1 — 5 стало ясно, что фабрика здесь подошла бы гораздо лучше.
Не вижу каким боком нас вылечит фабрика и решит проблемы с глобальной точкой входа и т.п.
B> Эссе в стиле "вредные советы"?
Это кому как.
Здравствуйте, rsn81, Вы писали:
R>Просто намекал, к примеру, на log4j, в котором singleton вроде бы достаточно умело обходит описанные вами выше проблемы.
У тебя есть шанс показать как именно и дать мне информацию к размышлениею.
Здравствуйте, minorlogic, Вы писали:
M>Я не знаю "почему рекомендуется ограничивать видимость метода GetInstance" и кем и когда тоже не знаю.
Бывает. Вероятно для того чтобы избежать зависимости всего и вся от этого синглтона.
B>>После ряда архитектурных ошибок допущеных в пп. 1 — 5 стало ясно, что фабрика здесь подошла бы гораздо лучше. M>Не вижу каким боком нас вылечит фабрика и решит проблемы с глобальной точкой входа и т.п.
Проблема глобальной точки входа решается созданием публичноего статического метода. А фабрика позволяла бы поставлять отдельный фичи только соостветствующим модулям. Чтобы все сразу не срали в сеть, к примеру.
Здравствуйте, minorlogic, Вы писали:
M>У тебя есть шанс показать как именно и дать мне информацию к размышлениею.
Да вы что, как мне повезло, однако! А мне вот кажется, что вы в состоянии реализовать свой шанс самостоятельно.
Здравствуйте, minorlogic, Вы писали:
M>Как большой любитель шаблона Singleton, хочу поговорить про использование этого шаблона для логирования. Логирование часто приводится как пример умесного применения сингелтона.
У логгера есть три функциональности:
1. Запись в хранилище.
2. Фильтрация.
3. Форматирование сообщений.
4. Обслуживание конф. файла чтобы все это собрать в целостное состояние.
Ессно, это не один класс а набор классов. При этом нужен максимально простой интерфейс. Вполне достаточно статических функций при настройке через конф. файл, то бишь IOC
M>2. Соседний отдел потребовал чтобы логер для их модуля отправлял по сети некие отладочные данные. У нас с этим проблем нету, сделали. Теперь сингелтон пишет в файл и кидает по сети.
Настрока конф. файла.
M>3. Еще один отдел потребовал чтобы все варнинги писались в системный лог ошибок. Без проблем сделали.
Настройка конф. файла.
M>4. Обнаружили что более 10 модулей в штатном режиме создают ТАКОЙ поток варнингов что от системного лога остается только пух и прах. На этом этапе приходится много думать. Появляется большое к-во полумер, но в итоге приходит решение , выставить для этого модуля некий флажок состояния в логере. Logger->SetEnableSys(true) и затем после отработки модуля опять в фолс.
Настройка конф. файла.
M>5. Отдел супер спецов утверждает что они хотят пользоваться своей имплементацией логера , которая позволит провести какие то тесты. После продолжительного бодания вы пишете сервисную функцию Logger->SetInstance(ILogger* );
Настройка конф. файла.
M>Конечным вариантом появляется или глобальная ф-ция Logger::Log(...) или LogService::GetLog().
Это были изначальные ошибки проектирования которые можно было обойти на начальном этапе.
Эссе в стиле "вредные советы"?
При этом нужен максимально простой интерфейс. Вполне достаточно статических функций при настройке через конф. файл, то бишь IOC