Прошу прощения за кросс постинг , но к сожалению по моей просьбе тему не перенесли. Я полагал что она превратиться в священную войну и сразу запостил в тот раздел. На удивление много постов было по существу и я предлагаю обсудить тему тут, в Архитектуре.
Как большой любитель шаблона 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().
Это были изначальные ошибки проектирования которые можно было обойти на начальном этапе.
Здравствуйте, minorlogic, Вы писали:
M>Как большой любитель шаблона Singleton, хочу поговорить про использование этого шаблона для логирования. Логирование часто приводится как пример умесного применения сингелтона.
Расскажи пожалуйста, как в описанной системе будет\может быть реализована следующая возможность: отключение логирования в зависимости от модуля, в котором логирование было вызвано, например, я не хочу логировать отрисовку графики, но хочу логировать сетевую активность. Причём оба модуля, отвечающие за графику и за сеть, имеют одну и ту жу точку входа к механизму логирования, как это сделано в приведённом примере: Logger->GetInstance(); Мне видится только один способ: коментирование всех вызовов логирования
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Расскажи пожалуйста, как в описанной системе будет\может быть реализована следующая возможность: отключение логирования в зависимости от модуля, в котором логирование было вызвано, например, я не хочу логировать отрисовку графики, но хочу логировать сетевую активность. Причём оба модуля, отвечающие за графику и за сеть, имеют одну и ту жу точку входа к механизму логирования, как это сделано в приведённом примере: Logger->GetInstance(); Мне видится только один способ: коментирование всех вызовов логирования
Мне кажется это ни коим образом не относится к теме ветки. Если тебя интересует как реализовать фильтрацию логирования , я советую поискать прямо на форуме. Тут было достаточно много веток про логи и интерфейсы к ним.
Здравствуйте, minorlogic, Вы писали:
M>Мне кажется это ни коим образом не относится к теме ветки. Если тебя интересует как реализовать фильтрацию логирования , я советую поискать прямо на форуме. Тут было достаточно много веток про логи и интерфейсы к ним.
Это имеет прямое отношение к реализации посредством синглетона. Какие известные системы логирования, основанные на синглетонах, это позволяют? Ещё раз, как это можно реализовать в описанной в корневом сообщении системе?
Мне не видно, как можно _хорошо_ и _удобно_ реализовать фильтрацию одновременно по различным ортоганальным уровням, таким как вызывающий модуль, важность (ошибка|предупреждение|информация), природа (исключение|логика).
З.Ы. Да и вежливость ответов отнюдь не располагает к дискуссии Это только мне кажется, или для чего топик был создан?
Критику синглетонов можно так же при желании отыскать на этом же самом форуме, а в корневом сообщении я не нашёл ни одного опровержения уже приведённых ранее доводов Ты надеешься что в очередной раз IB и WolfHound поленятся мучить свои клавиатуры? Так вот судя по манере ответов, правильно сделают
Help will always be given at Hogwarts to those who ask for it.
Ты пытаешься увести тему в сторону , я вежливо обращаю на это внимание. Мне лично в этой теме не хочется обсуждать офтопики, возможно ктонить захочет вести с тобой диалог по заданному направлениею.
Здравствуйте, minorlogic, Вы писали:
M>Ты пытаешься увести тему в сторону , я вежливо обращаю на это внимание. Мне лично в этой теме не хочется обсуждать офтопики, возможно ктонить захочет вести с тобой диалог по заданному направлениею.
Тебе пытаются объяснить очень простую вещь: невозможно обсуждать преимущества и недостатки синглтона на примере его некорректного использования.
Я не IB и не Wolfhound, я, в отличие от них, считаю что синглтон вполне имеет право на жизнь. Но даже меня твой пример коробит.
Здравствуйте, _FRED_, Вы писали:
_FR>Это имеет прямое отношение к реализации посредством синглетона. Какие известные системы логирования, основанные на синглетонах, это позволяют? Ещё раз, как это можно реализовать в описанной в корневом сообщении системе?
_FR>Мне не видно, как можно _хорошо_ и _удобно_ реализовать фильтрацию одновременно по различным ортоганальным уровням, таким как вызывающий модуль, важность (ошибка|предупреждение|информация), природа (исключение|логика).
Синглтоновость тут как раз не помеха и ServiceProvider не помощник в фильтрации. Модуль надо маркировать явно. Почему я так думаю:
Модули вызывают друг друга и если мне с верхнего уровня доступна только бизнес-логика, то я лучшем случае могу создать UserLogger и OrderLogger, но не DatabaseLogger или NetworkLogger. Подобные детали скрыты и позволять создавать логегры на любом уровня я считаю большой ошибкой. В результате мы всё равно придём к использования синглтона, так как откуда-то надо брать настройки логгеров, только это будет хорошо замаскированный и сильно запутанный синглтон.
Модули которые вызывают логгер не всегда являются характеризующими. Например, сетевой трафик при скачивании курса валют с сайта ЦБ и сетевой трафик при отсылке данных об ошибке приложения оба HTTP трафики, но писать просто NetworkModule ИМХО не правильно.
Здравствуйте, minorlogic, Вы писали:
R>>Просто намекал, к примеру, на log4j, в котором singleton вроде бы достаточно умело обходит описанные вами выше проблемы. M>У тебя есть шанс показать как именно и дать мне информацию к размышлениею.
Достаточно просто. В начале нужного класса ставишь делаешь так:
public class SomeClass
{
private final static Log log=LogFactory.getLogger(SomeClass.class);
...
void someMethod()
{
log.error("An error!");
log.debug("Debug");
...
}
...
}
И настраиваешь:
# Set root logger level to WARN and its only appender to A1.
log4j.rootLogger=WARN, A1
# A1 is set to be a ConsoleAppender.
log4j.appender.A1=org.apache.log4j.ConsoleAppender
# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n
# Print debug info for our classes
log4j.logger.com.ourapp=DEBUG
# Don't print too much debug info
log4j.logger.com.ourapp.SomeClass=WARN
То есть, выбор формата лога и уровня отладки выносится из основного кода.
Там еще есть более мощная XML-конфигурация, но мне ни разу не приходилось с ней сталкиваться.
Здравствуйте, adontz, Вы писали:
A>Тебе пытаются объяснить очень простую вещь: невозможно обсуждать преимущества и недостатки синглтона на примере его некорректного использования.
Может оттого что такого примера коректного использования нет ?
A>Я не IB и не Wolfhound, я, в отличие от них, считаю что синглтон вполне имеет право на жизнь. Но даже меня твой пример коробит.
Это больше похоже на вариант который продемонстирован в конце и у которого есть четкое разделение на глобальную точку входа "LogFactory.getLogger(SomeClass.class);" и остальное.
или переформулируя вопрос , неужели LogFactory гденить вызывает getInstance. ?
Здравствуйте, minorlogic, Вы писали:
A>>Тебе пытаются объяснить очень простую вещь: невозможно обсуждать преимущества и недостатки синглтона на примере его некорректного использования. M>Может оттого что такого примера корректного использования нет ?
Твой пример помимо использования синглтона содержит множество других моментов, которые вызывают сомнение в профессионализме автора. На это тебе уже неоднократно указали.
Что касается моего личного мнения, я его уже высказал: синглтоном должна быть конфигурация логгера. Это очень хорошо отражено в описании ULP — "ULP configuration would not be available at the 'user' level, it would be a system service.". Это не бред кучки фанатиков, это требование объективной реальности. Я, как человек, имеющий отношение не только к созданию, но и к последующему сопровождению систем, как человек активно общающийся с системными администраторами и сам обладающими достаточно большими навыками в этой области могу лично подтвердить на примерах из жизни, почему журналирование надо настраивать для уровне системы, а не отдельных приложений. Я уже дал ссылки на другие материалы по теме, в частности на RFC протокола SysLog, но читать ты их не хочешь, ты хочешь солировать. К сожалению ничего умного или хотя бы интересного от тебя не исходит, ты упрямо гнёшь своё. Мне общаться с человеком который приводит нелепые примеры для доказательства тезисов в сфере, в которой он ничего не понимает, не интересно.
Общайся ты в форме диалога, задавая вопросы и выдвигая предположения, было бы лучше. Ты же продемонстрировал абсолютно неадекватно спроектированную систему, обозначил какие-то проблемы второго плана, сделал из их наличия "выводы" и теперь высокомерно учишь окружающих как жить. Кавычки у слова "выводы" не случайны, так как твой ход мыслей и логика две вещи несовместимые.
Кончай этот балаган и ознакомься с существующими системами, стандартами, документами. А вот потом поговорим.
Здравствуйте, minorlogic, Вы писали:
M>Это больше похоже на вариант который продемонстирован в конце и у которого есть четкое разделение на глобальную точку входа "LogFactory.getLogger(SomeClass.class);" и остальное. M>или переформулируя вопрос , неужели LogFactory гденить вызывает getInstance. ?
Собственно, да. Точнее, не getInstance(), а просто использует статическую переменную.
Здравствуйте, adontz, Вы писали:
A>Твой пример помимо использования синглтона содержит множество других моментов, которые вызывают сомнение в профессионализме автора. На это тебе уже неоднократно указали.
Я ему передам.
A>Что касается моего личного мнения, я его уже высказал: синглтоном должна быть конфигурация логгера. Это очень хорошо отражено в описании ULP — "ULP configuration would not be available at the 'user' level, it would be a system service.". Это не бред кучки фанатиков, это требование объективной реальности. Я, как человек, имеющий отношение не только к созданию, но и к последующему сопровождению систем, как человек активно общающийся с системными администраторами и сам обладающими достаточно большими навыками в этой области могу лично подтвердить на примерах из жизни, почему журналирование надо настраивать для уровне системы, а не отдельных приложений. Я уже дал ссылки на другие материалы по теме, в частности на RFC протокола SysLog, но читать ты их не хочешь, ты хочешь солировать. К сожалению ничего умного или хотя бы интересного от тебя не исходит, ты упрямо гнёшь своё. Мне общаться с человеком который приводит нелепые примеры для доказательства тезисов в сфере, в которой он ничего не понимает, не интересно.
А мне неинтересно ТВОЕ мнение. Надеюсь на том и разойдемся.
A>Общайся ты в форме диалога, задавая вопросы и выдвигая предположения, было бы лучше. Ты же продемонстрировал абсолютно неадекватно спроектированную систему, обозначил какие-то проблемы второго плана, сделал из их наличия "выводы" и теперь высокомерно учишь окружающих как жить. Кавычки у слова "выводы" не случайны, так как твой ход мыслей и логика две вещи несовместимые.
Если ты не разобрался о чем был пост, то это ТВОИ проблемы. Напомню что у меня не было задачи описывать адекватно спроектированную систему логирования.
A>Кончай этот балаган и ознакомься с существующими системами, стандартами, документами. А вот потом поговорим.
Мне с ТОБОЙ говорить уже нет желания , а вот выводы о том что я этими системами не знаком прошу считать ошибочными.
Здравствуйте, minorlogic, Вы писали:
A>>Твой пример помимо использования синглтона содержит множество других моментов, которые вызывают сомнение в профессионализме автора. На это тебе уже неоднократно указали. M>Я ему передам.
Передай. Думаешь я против? Я эти слова могу сказать лично, в лицо. Я ни от кого не прячусь и пугать меня каким-то мифическим гуру не надо.
M>А мне неинтересно ТВОЕ мнение. Надеюсь на том и разойдемся.
Смешно ей богу. Я даю ссылки на официальные документы, а тебе не интересно видите ли моё мнение. А мнение мировой общественности?
M>Если ты не разобрался о чем был пост, то это ТВОИ проблемы. Напомню что у меня не было задачи описывать адекватно спроектированную систему логирования.
Пост был ни о чём, так как содержал слишком много ошибок проектирования. Показать что глобальная точка доступа и синглтон разные вещи тебе не удалось, потому что у тебя там нет адекватно применённого синглтона и нет, на самом деле, даже глобальной точки доступа.
A>>Кончай этот балаган и ознакомься с существующими системами, стандартами, документами. А вот потом поговорим. M>Мне с ТОБОЙ говорить уже нет желания , а вот выводы о том что я этими системами не знаком прошу считать ошибочными.
Я об этом сужу по коду, который ты предоставил. Метод SetInstance — это код студента. Вот пусть кто хочет, тот и обижается, но я бы за такие решения с должности архитектора снимал.
Эссе в стиле "вредные советы"?
При этом нужен максимально простой интерфейс. Вполне достаточно статических функций при настройке через конф. файл, то бишь IOC
Мне видится только один способ: коментирование всех вызовов логирования 
Так вот судя по манере ответов, правильно сделают 
