Re: Насколько "вредно" использование singleton?
От: jazzer Россия Skype: enerjazzer
Дата: 26.07.10 10:14
Оценка: 1 (1) +6 :))) :))
Здравствуйте, Аноним, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?


Практически всегда, когда я писал синглтон, наступал момент, когда мне нужно было два таких объекта.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Насколько "вредно" использование singleton?
От: kjam Украина  
Дата: 26.07.10 17:15
Оценка: 8 (2) +2
Я знаю только три случая когда класс можно делать синглтоном:

1. Состояние объекта не меняется на протяжении времени его жизни и это состояние можно полностью описать в программном коде/ресурсах — состояние не зависит от текущего времени, содержимого конфигурационных файлов, переменных окружения и т.п. Но синглтон вполне может грузить какие-либо ресурсы, которые считаются "вшитыми" в приложение. Т.е. синглтон является не глобальной переменной, а глобальной константой.

2. Синглтон является расширением рантайма, частью машины которая исполняет нашу программу. (Например — отладочное (!) логирование)

3. Синглтон используется для внедрения какого-либо хака. При этом надо четко осознавать что делается именно хак, и соответственным образом документировать эту ситуацию.

Во всех других случаях считаю использование синглтонов считаю неприемлемым.
Re[21]: Насколько "вредно" использование singleton?
От: Тот кто сидит в пруду Россия  
Дата: 27.07.10 19:20
Оценка: +3
Здравствуйте, Ikemefula, Вы писали:

I>Локатор дает доступ к самым различным сервисам, а не только к логгеру.


I>Логгер — это т.н. сквозной функционал, ты что, будешь для каждого такого сервиса синглтон городить ?


I>Используя dependency injection у тебя получится примерно так


I>
I>classA::classA(ILogger* pLogger)
I>{
  this->>pLogger = pLogger;
I>}
I>


I>или так


I>
I>classA::SetLogger(ILogger* pLogger)
I>{
  this->>pLogger = pLogger;
I>}
I>


I>И это будет работать _само_


Глупости неудобные. Не надо вносить общность там, где она не требуется. Для логгирования удобен интерфейс в стиле

MyLog(level) << "some message";


для других сервисов — какой-то другой. А уж внутри MyLog хоть сервислокатор зови, хоть к синглтону обращайся — особой разницы нет.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re: Насколько "вредно" использование singleton?
От: Кодёнок  
Дата: 26.07.10 11:27
Оценка: 1 (1) -1
Здравствуйте, Аноним, Вы писали:

А>Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках).


Синглтон не вреден или неправилен, он просто нахрен не нужен. И кстати application во многих фреймворках просто глобальная переменная, а не «умный» синглтон.
Re[5]: Насколько "вредно" использование singleton?
От: szag  
Дата: 26.07.10 13:20
Оценка: +2
Здравствуйте, sidorov18, Вы писали:

S>У меня, например, синглтоном класс лог.

S>А еще есть класс-синглтон, который контент из нета качает и парсит в свои структуры.

всегда может понадобится второй лог и работа через несколько соединений. Чисто моё имхо, в идеальной программе сингелтонов быть не должно. Практически всегда может потребоваться вторая копия объекта и исправить это будет не так просто, как изначально отказаться от использования синглтонов.
Re[2]: Насколько "вредно" использование singleton?
От: Юрий Жмеренецкий ICQ 380412032
Дата: 27.07.10 03:49
Оценка: +1 :)
Здравствуйте, minorlogic, Вы писали:

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


M>Вреден ровно настолько насколько глобальные данные.


Хуже. В отношении глобальных данных не возникает желания выделенного
Re[11]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 11:03
Оценка: +1 -1
Здравствуйте, enji, Вы писали:

I>>Проблема в том, что класс получается зависимым от системы логирования.


E>А как иначе? Код, который что-то логирует, безусловно зависит от системы логиривания. Класс, который сохраняет сообщения лога куда-либо, так же зависит от системы логирования.


Иначе — зависимость только от интерфейса для логирования а не всей системы или синглтона какого.

E>Однако обработчики лог-сообщений надо где-то регистрировать и вызываться в случае появления очередного сообщения. Вот тут и нужны какие-то глобальные данные, вероятно завернутые в синглтон. Этот синглтон может быть скрыт в реализации системы логирования и не виден никому, однако он всяко будет...


Он то будет, но сути это не меняет. Если класс зависит от какого то синглтона и тд, то во время отладки нужно подменить этот синглтон и тд и тд.

А если зависит только от интерфейса, то достаточно конкретный класс инициализировать определенным образом.
Re: Насколько "вредно" использование singleton?
От: minorlogic Украина  
Дата: 26.07.10 14:24
Оценка: 6 (1)
Здравствуйте, <Аноним>, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?


Вреден ровно настолько насколько глобальные данные.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Насколько "вредно" использование singleton?
От: rm822 Россия  
Дата: 26.07.10 11:31
Оценка: 3 (1)
J>Практически всегда, когда я писал синглтон, наступал момент, когда мне нужно было два таких объекта.

для С++ больше подходит monostate
http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Насколько "вредно" использование singleton?
От: Guard_h4s Россия  
Дата: 26.07.10 12:11
Оценка: 1 (1)
Здравствуйте, Аноним, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?


Вообще, синглтон повышает связанность(coupling) вашего кода. Это не значит что это плохо, но иногда может мешать(например написанию юнит тестов)
Вносится дополнительное глобальное состояние всей программы. Однако удобства его использования чаще всего склоняют в сторону его использования (мы использовали в проекте где 1М строк кода) Здесь не рассматривается вариант "мы используем синглтон потому что лень следить/управлять временем жизни объекта". Как правило это именно централизованый доступ, а не управление временем жизни объекта(CreateInstance(), DestroyInstance() присутствуют всегда явно, или объект вообще создается на стеке) В случае с многопоточностью, как правило, это один объект на поток(что также неплохо ложится на TLS)
Re: Насколько "вредно" использование singleton?
От: Sni4ok  
Дата: 26.07.10 20:29
Оценка: +1
Здравствуйте, Аноним, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять


использовать синглетоны совсем не вредно, поэтому используйте на здоровье.
Re[3]: Насколько "вредно" использование singleton?
От: Тот кто сидит в пруду Россия  
Дата: 26.07.10 21:11
Оценка: +1
Здравствуйте, Centaur, Вы писали:

K>>2. Синглтон является расширением рантайма, частью машины которая исполняет нашу программу. (Например — отладочное (!) логирование)


C>Это сегодня программа однопоточная, и отладочное логирование можно сделать синглтоном. А завтра появится новый поток, и привет. Пользоваться из двух потоков одним отладочным логом без синхронизации — портить лог. Городить синхронизацию — а нафиг тогда потоки? Остаётся только делать по отдельному логу на каждый поток.


1) Вообще любой из этих вариантов (а так же более сложные) можно спрятать внутрь синглтона. Хотя функциональный интерфейс по мне так удобнее.
2) При переделке однопоточной программы в многопоточную будет куча куда более серьезных проблем, чем доступ к логу
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[8]: Насколько "вредно" использование singleton?
От: enji  
Дата: 27.07.10 07:52
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Sni4ok, Вы писали:


I>>>Лог это как раз пример того, что не должно быть синглтоном


S>>плохой пример, тоесть понятно дело вызов логирования — это как правило либо функция, либо обьект с деструктором, либо макрос поверх чего-то этого, но в любом случае эта функция или деструктор этого обьекта будет обращаться к какому-то глобальному обьекту(банально хендл файла к примеру куда пишется).


I>А надо будет тебе лог какого объекта перенаправть для отладки например на экран, что будешь делать ?


А в чем проблема? Напишу класс LogToScreen, зарегистрирую его в системе логирования и дальше буду получать интересующие меня сообщения на экран... Объеты, которые пишут в лог, никак при этом не изменятся.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re: Насколько "вредно" использование singleton?
От: okman Беларусь https://searchinform.ru/
Дата: 27.07.10 10:40
Оценка: +1
Здравствуйте, Аноним, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?


Синглетон — очень удобная штука, просто легко забыть что именно он из себя представляет и
использовать его не по назначению. А еще это многие сотни или тысячи extern-ов, которые
теперь не нужно включать во все исходные файлы, где синглетон используется, как это было
бы в случае с глобальными объектами. И временем жизни данного объекта тоже можно
управлять (вспоминается синглетон-феникс), чего о глобальных объектах не скажешь.
Кстати, упорядоченность инициализации/разрушения глобальных и статических объектов — это
общая проблема проектирования, присущая не только синглетонам.

В среде, где я работаю, принято простые объекты-синглетоны переопределять специальным образом:

typedef Singleton<CService, ThreadingModel<Multi> > S_Service;


или даже

#define S_ServiceState Singleton<CService, ThreadingModel<Multi> >::instance().state()


В результате имеем компактный и понятный синтаксис типа:

if (S_ServiceState != FALSE)
{
...
}
Re[13]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 13:30
Оценка: -1
Здравствуйте, blackhearted, Вы писали:

I>>А как можно сделать "создаёт нужную категогрию логирования " без зависимости от системы логирования ?


B>вызывая

B>
B>logSingleton.createCategory("someString");
B>


B>C таким подходом вообще всё логирование — это зависимость от системы логирования.


В данном случае ты проблему зависимости решил с помощью синглтона.

Это именно тот случай, где синглтон не стоит применять.
Re[22]: Насколько "вредно" использование singleton?
От: enji  
Дата: 28.07.10 09:19
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

E>>Или же этот реестр будет хранить что-то вроде void*, а затем будет иметься кошмарный интерфейс вида reestr::get<LogSystem>()->log("bla bla")


I>Реестр будет хранить то, что в него напихал конфигуратор.


Ну и как напиханное получать?

E>>И чем такой подход лучше?


I>слабая связанность, теструемость, реюзабельность, прозрачность


Хорошо. Давайте на примере. Чем запись LogSystem::get() лучше reestr::get()->get<LogSystem>() ?

Как именно это улучшает:
— связность (ведь клиенты лога по прежнему должны иметь доступ к его интерфейсу + теперь еще и к интерфейсу реестра)?
— тестируемость (ведь лог пишет в указанные ему обработчики, надо проверить взаимодействие класса и лога — просто создаем спец обработчик для тестов и анализируем, что ему пришло)?
— реюзабельность (система логирования вполне устоявшаяся штука, реюзается из проекта в проект; вы же предлагаете вместе с ней реюзать еще и реестр)?
— прозрачность (чем непрозрачна обычная система логирования, зачем привлекать еще и специальный реестр)?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Насколько "вредно" использование singleton?
От: Аноним  
Дата: 26.07.10 10:10
Оценка:
После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?
Re[2]: Насколько "вредно" использование singleton?
От: sidorov18 США  
Дата: 26.07.10 11:32
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Аноним, Вы писали:


А>>Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках).


Кё>Синглтон не вреден или неправилен, он просто нахрен не нужен. И кстати application во многих фреймворках просто глобальная переменная, а не «умный» синглтон.


хм. нужен только один инстанс объекта на всю программу. какая альтернатива синглтону?
Re: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.07.10 11:38
Оценка:
Здравствуйте, Аноним, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?


Синглтон это такая вещь, которая почти всегда используюется неправильно

Когда лень думать про инициализацию — берут синглтон
Лень думать про передачу ссылки — берут синглтон
Нужн только один инстанц — берут синглтон
Re[3]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.07.10 11:39
Оценка:
Здравствуйте, sidorov18, Вы писали:

Кё>>Синглтон не вреден или неправилен, он просто нахрен не нужен. И кстати application во многих фреймворках просто глобальная переменная, а не «умный» синглтон.


S>хм. нужен только один инстанс объекта на всю программу. какая альтернатива синглтону?


А по подробнее можно унать, что за класс объекта и почему только один инстанс ?
Re[4]: Насколько "вредно" использование singleton?
От: sidorov18 США  
Дата: 26.07.10 11:50
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, sidorov18, Вы писали:


Кё>>>Синглтон не вреден или неправилен, он просто нахрен не нужен. И кстати application во многих фреймворках просто глобальная переменная, а не «умный» синглтон.


S>>хм. нужен только один инстанс объекта на всю программу. какая альтернатива синглтону?


I>А по подробнее можно унать, что за класс объекта и почему только один инстанс ?


Я не топикстартер.
Я вообще

У меня, например, синглтоном класс лог.
А еще есть класс-синглтон, который контент из нета качает и парсит в свои структуры.
Re[2]: Насколько "вредно" использование singleton?
От: enji  
Дата: 26.07.10 11:52
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>Синглтон не вреден или неправилен, он просто нахрен не нужен. И кстати application во многих фреймворках просто глобальная переменная, а не «умный» синглтон.


Ну так глобальная переменная — это и есть простейший вариант синглтона, нет?

А всякие обертки нужны чтобы разрулить порядок инициализации и время жизни...
Re[3]: Насколько "вредно" использование singleton?
От: enji  
Дата: 26.07.10 12:30
Оценка:
Здравствуйте, rm822, Вы писали:

R>для С++ больше подходит monostate

R>http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf

Почитал, не понял в чем преимущество monostate.

class TMonostate
{
  static std::string s;

public:

  const std::string& getS() { return s; }
  
};


В таком виде использовать не получится, так как до входа в main() TMonostate::s может быть неинициализирована. Т.е. внутри надо городить синглетон, оберткой для которого будет этот TMonostate. Тогда в чем преимущество?
Re[2]: Насколько "вредно" использование singleton?
От: Faust Россия  
Дата: 26.07.10 12:34
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>Синглтон не вреден или неправилен, он просто нахрен не нужен.

не соглашусь... и поддержу sidorov18'а
Автор: sidorov18
Дата: 26.07.10
в его ссылке на практическую задачу о логгировании, которая особенно усугубляется в многопоточной среде, которая существенно усложняет реализацию singleton'а. другое дело, что использование этого паттерна должно быть осознанным и аргументированным, а также вязаться с программным интерфейсом приложения, которое в дальнейшем кто-то будет поддерживать...
Мой компьютер прогоняет бесконечный цикл за 9 секунд, но, мне кажется, он мог бы сделать это быстрее...
Re[4]: Насколько "вредно" использование singleton?
От: rm822 Россия  
Дата: 26.07.10 12:57
Оценка:
E>В таком виде использовать не получится, так как до входа в main() TMonostate::s может быть неинициализирована. Т.е. внутри надо городить синглетон, оберткой для которого будет этот TMonostate. Тогда в чем преимущество?
Преимущество будет когда выясниться что объектов нифига не один, и что закладываться на это везде в коде было большой ошибкой
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.07.10 14:37
Оценка:
Здравствуйте, sidorov18, Вы писали:

S>Я не топикстартер.

S>Я вообще

S>У меня, например, синглтоном класс лог.


Лог это как раз пример того, что не должно быть синглтоном

S>А еще есть класс-синглтон, который контент из нета качает и парсит в свои структуры.


И это тоже
Re[5]: Monostate
От: enji  
Дата: 26.07.10 17:18
Оценка:
Здравствуйте, rm822, Вы писали:

E>>В таком виде использовать не получится, так как до входа в main() TMonostate::s может быть неинициализирована. Т.е. внутри надо городить синглетон, оберткой для которого будет этот TMonostate. Тогда в чем преимущество?

R>Преимущество будет когда выясниться что объектов нифига не один, и что закладываться на это везде в коде было большой ошибкой

Ну т.е. monostate — это исключительно обертка над синглетоном. С тем же успехом можно возвращать из функции TSingleton::get() умный указатель. А если выяснится, что синглтон на самом деле не синглтон, то эта функция будет создавать объекты (возможно получая какие-то опциональные параметры), а не возвращать указатель на статический...
Re[2]: Насколько "вредно" использование singleton?
От: Centaur Россия  
Дата: 26.07.10 20:09
Оценка:
Здравствуйте, kjam, Вы писали:

K>2. Синглтон является расширением рантайма, частью машины которая исполняет нашу программу. (Например — отладочное (!) логирование)


Это сегодня программа однопоточная, и отладочное логирование можно сделать синглтоном. А завтра появится новый поток, и привет. Пользоваться из двух потоков одним отладочным логом без синхронизации — портить лог. Городить синхронизацию — а нафиг тогда потоки? Остаётся только делать по отдельному логу на каждый поток.
Re[6]: Насколько "вредно" использование singleton?
От: Sni4ok  
Дата: 26.07.10 20:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Лог это как раз пример того, что не должно быть синглтоном


плохой пример, тоесть понятно дело вызов логирования — это как правило либо функция, либо обьект с деструктором, либо макрос поверх чего-то этого, но в любом случае эта функция или деструктор этого обьекта будет обращаться к какому-то глобальному обьекту(банально хендл файла к примеру куда пишется).
Re[2]: Насколько "вредно" использование singleton?
От: Sni4ok  
Дата: 26.07.10 20:40
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Вреден ровно настолько насколько глобальные данные.


а может быть и меньше, из конструктора глобального обьекта нельзя кидать исключения, из конструктора обьекта-синглетона можно кидать исключения, если синглетон это допускает.
Re[4]: Насколько "вредно" использование singleton?
От: DIMEDROLL Украина  
Дата: 27.07.10 04:10
Оценка:
Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>1) Вообще любой из этих вариантов (а так же более сложные) можно спрятать внутрь синглтона.

согласен, сделать синглтон потокобезопасным, добавив в его методы лок\анлок мютекса.
Re[7]: Насколько "вредно" использование singleton?
От: szag  
Дата: 27.07.10 06:53
Оценка:
Здравствуйте, Sni4ok, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:


I>>Лог это как раз пример того, что не должно быть синглтоном


S>плохой пример, тоесть понятно дело вызов логирования — это как правило либо функция, либо обьект с деструктором, либо макрос поверх чего-то этого, но в любом случае эта функция или деструктор этого обьекта будет обращаться к какому-то глобальному обьекту(банально хендл файла к примеру куда пишется).


Логи могут писаться в разные файлы на разных дисках. В разные БД и таблицы, включая удаленные сервера с выбором наименее загруженного сервера. Логи могут посылаться по сети через разные соединения и еще куча всяких примеров, как может быть организовано логирование. Вообще, ИМХО, система логирования должна гибко настраиваться в конфигурационных фалайх
Re[7]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 07:22
Оценка:
Здравствуйте, Sni4ok, Вы писали:

I>>Лог это как раз пример того, что не должно быть синглтоном


S>плохой пример, тоесть понятно дело вызов логирования — это как правило либо функция, либо обьект с деструктором, либо макрос поверх чего-то этого, но в любом случае эта функция или деструктор этого обьекта будет обращаться к какому-то глобальному обьекту(банально хендл файла к примеру куда пишется).


А надо будет тебе лог какого объекта перенаправть для отладки например на экран, что будешь делать ?
Re[9]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 08:00
Оценка:
Здравствуйте, enji, Вы писали:

I>>А надо будет тебе лог какого объекта перенаправть для отладки например на экран, что будешь делать ?


E>А в чем проблема? Напишу класс LogToScreen, зарегистрирую его в системе логирования и дальше буду получать интересующие меня сообщения на экран... Объеты, которые пишут в лог, никак при этом не изменятся.


Проблема в том, что класс получается зависимым от системы логирования.
Re[10]: Насколько "вредно" использование singleton?
От: enji  
Дата: 27.07.10 09:30
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, enji, Вы писали:


I>>>А надо будет тебе лог какого объекта перенаправть для отладки например на экран, что будешь делать ?


E>>А в чем проблема? Напишу класс LogToScreen, зарегистрирую его в системе логирования и дальше буду получать интересующие меня сообщения на экран... Объеты, которые пишут в лог, никак при этом не изменятся.


I>Проблема в том, что класс получается зависимым от системы логирования.


А как иначе? Код, который что-то логирует, безусловно зависит от системы логиривания. Класс, который сохраняет сообщения лога куда-либо, так же зависит от системы логирования.

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

Однако обработчики лог-сообщений надо где-то регистрировать и вызываться в случае появления очередного сообщения. Вот тут и нужны какие-то глобальные данные, вероятно завернутые в синглтон. Этот синглтон может быть скрыт в реализации системы логирования и не виден никому, однако он всяко будет...
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[5]: Насколько "вредно" использование singleton?
От: Тот кто сидит в пруду Россия  
Дата: 27.07.10 09:40
Оценка:
Здравствуйте, DIMEDROLL, Вы писали:

ТКС>>1) Вообще любой из этих вариантов (а так же более сложные) можно спрятать внутрь синглтона.

DIM>согласен, сделать синглтон потокобезопасным, добавив в его методы лок\анлок мютекса.

Не обязательно, можно через синглтон организовать доступ к нескольким логам, по одному на нить — если кому-то вдруг такое понадобится.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[6]: Monostate
От: rm822 Россия  
Дата: 27.07.10 09:45
Оценка:
E>Ну т.е. monostate — это исключительно обертка над синглетоном.
нет, это разные концепции
синглтон однозначно связывает тип с единственным его экземпляром. Стейт однозначно связывается с поведением.
Моностейт разделяет состояние и поведение.

Обычно использование моностейта более выгодно если к нему много обращений, т.к. растет потребность в небольших вариациях поведения

как к примеру выглядит запись в лог в контексте какого-то класса
вариант с синглтоном
class MyClass
{
  void Log(PCWSTR message)
    {
       std::wstringstream ss;
         ss << //пишем контекст this
         ss << message;
         Logger::Instance().Write(ss.str());
    }
    
    void Meth()
    {
      Log(L"Entering meth...");
        ....
    }
}


очевидный минус — мы слегка изгадили дизайн, возложив на MyClass логирование
используя моностейт этот недостаток можно исправить

class MyClassLogger: public Logger
{
   void operator()(MyClass* ctx, PCWSTR message)
     {
       std::wstringstream ss;
         ss << //пишем контекст ctx
         ss << message;
         Write(ss.str());
      }
}

class MyClass
{
  MyClassLogger log;
    void Meth()
    {
      log(this, L"Entering meth...");
        ....
    }
}
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Насколько "вредно" использование singleton?
От: DIMEDROLL Украина  
Дата: 27.07.10 09:58
Оценка:
Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Не обязательно, можно через синглтон организовать доступ к нескольким логам, по одному на нить — если кому-то вдруг такое понадобится.

Как?
В методе write() определять ID потока и писать в соответствующий потоку файл?
Re[7]: Насколько "вредно" использование singleton?
От: Тот кто сидит в пруду Россия  
Дата: 27.07.10 10:19
Оценка:
Здравствуйте, DIMEDROLL, Вы писали:

ТКС>>Не обязательно, можно через синглтон организовать доступ к нескольким логам, по одному на нить — если кому-то вдруг такое понадобится.

DIM>Как?
DIM>В методе write() определять ID потока и писать в соответствующий потоку файл?

Можно так, можно с помощью TLS (например, boost::thread_specific_ptr) разрулить.
А вообще, идея с несколькими файлами лога мне не нравится. По-хорошему надо бы просто завести по буферу на поток, чтобы не терять много на синхронизации, из которых потом (когда наберется цельная запись лога) асинхронно (overlapped I/O) сбрасывать все в один файл.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[8]: Насколько "вредно" использование singleton?
От: Sni4ok  
Дата: 27.07.10 10:44
Оценка:
Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>По-хорошему надо бы просто завести по буферу на поток, чтобы не терять много на синхронизации, из которых потом (когда наберется цельная запись лога) асинхронно (overlapped I/O) сбрасывать все в один файл.


всё равно эту запись(хоть и асинхронную) вам придётся синхронизировать, да и ждать- пока наберётся нужное количество информации, чтобы записать- утопично, поскольку где гарантия что, программа не рухнет прямо через мгновение, а вы потеряете ту информацию ради которой и велось логирование?
Re[10]: Насколько "вредно" использование singleton?
От: blackhearted Украина  
Дата: 27.07.10 11:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, enji, Вы писали:


I>>>А надо будет тебе лог какого объекта перенаправть для отладки например на экран, что будешь делать ?


E>>А в чем проблема? Напишу класс LogToScreen, зарегистрирую его в системе логирования и дальше буду получать интересующие меня сообщения на экран... Объеты, которые пишут в лог, никак при этом не изменятся.


I>Проблема в том, что класс получается зависимым от системы логирования.


Не факт, можно всё через конфиги зарегистрировать да и всё. Класс создаёт нужную категогрию логирования и если для неё нет отдельной настройки — она пишется в дефолтный лог, а если есть — то уже как настроят.
Re[11]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 11:16
Оценка:
Здравствуйте, blackhearted, Вы писали:

I>>Проблема в том, что класс получается зависимым от системы логирования.


B>Не факт, можно всё через конфиги зарегистрировать да и всё. Класс создаёт нужную категогрию логирования и если для неё нет отдельной настройки — она пишется в дефолтный лог, а если есть — то уже как настроят.


А как можно сделать "создаёт нужную категогрию логирования " без зависимости от системы логирования ?
Re[12]: Насколько "вредно" использование singleton?
От: blackhearted Украина  
Дата: 27.07.10 12:10
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:


I>>>Проблема в том, что класс получается зависимым от системы логирования.


B>>Не факт, можно всё через конфиги зарегистрировать да и всё. Класс создаёт нужную категогрию логирования и если для неё нет отдельной настройки — она пишется в дефолтный лог, а если есть — то уже как настроят.


I>А как можно сделать "создаёт нужную категогрию логирования " без зависимости от системы логирования ?


вызывая
logSingleton.createCategory("someString");



C таким подходом вообще всё логирование — это зависимость от системы логирования.
Re[9]: Насколько "вредно" использование singleton?
От: Тот кто сидит в пруду Россия  
Дата: 27.07.10 12:50
Оценка:
Здравствуйте, Sni4ok, Вы писали:

ТКС>>По-хорошему надо бы просто завести по буферу на поток, чтобы не терять много на синхронизации, из которых потом (когда наберется цельная запись лога) асинхронно (overlapped I/O) сбрасывать все в один файл.


S>всё равно эту запись(хоть и асинхронную) вам придётся синхронизировать,


Нифига, эта забота операционки. Да и вообще, подобную операцию можно выполнять достаточно эффективно, даже если ОС не умеет асинхронную запись, коллизии на синхронизации в реальной программе будут очень редкими.

S>да и ждать- пока наберётся нужное количество информации, чтобы записать- утопично, поскольку где гарантия что, программа не рухнет прямо через мгновение, а вы потеряете ту информацию ради которой и велось логирование?


Речь идет о конструкциях следующего вида:

MyLog(10) << "doing something with: " << obj.Name() << " and " << obj2.Name();


Конец строки (вернее, разрушение анонимного объекта типа MyLog) — сброс буфера. Потерять половину подобного буфера считаю вполне приемлемым. Если и это не устраивает, целесообразнее будет завести отдельный сервис логгирования, а не мучатся с отдельным файлом для каждой нитки.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[12]: Насколько "вредно" использование singleton?
От: enji  
Дата: 27.07.10 13:10
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, enji, Вы писали:


I>>>Проблема в том, что класс получается зависимым от системы логирования.


E>>А как иначе? Код, который что-то логирует, безусловно зависит от системы логиривания. Класс, который сохраняет сообщения лога куда-либо, так же зависит от системы логирования.


I>Иначе — зависимость только от интерфейса для логирования а не всей системы или синглтона какого.


Ну дык я об этом и говорю... Подразумевается, что система логирования имеет два "интерфейса" — один для регистрации обработчиков, второй — для логирования.

первый — это класс LogStream, второй — интерфейс обработчика, класс LogMessage и функция registerProcessor()

Но внутри то сидят общие данные, к которым полезут как LogStream, так и registerProcessor. Наружу они не видны, клиенты от них не зависят. Дальше есть два варианта — или эти данные глобальны, или LogStream и registerProcessor дополнительно получают некую ссылку. Возможно это наиболее универсальный способ, но тогда надо что бы тот, кто хочет что-нить логировать, имел эту ссылку. ИМХО, таскать во многих объектах такую ссылку нифига не удобно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[13]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 13:27
Оценка:
Здравствуйте, enji, Вы писали:

E>первый — это класс LogStream, второй — интерфейс обработчика, класс LogMessage и функция registerProcessor()


Это уже слишком много

E>ИМХО, таскать во многих объектах такую ссылку нифига не удобно.


Конечно неудобно, но это не значит, что для решения этой проблемы нужно создавать синглтон.
Re[10]: Насколько "вредно" использование singleton?
От: Sni4ok  
Дата: 27.07.10 13:37
Оценка:
Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Если и это не устраивает, целесообразнее будет завести отдельный сервис логгирования, а не мучатся с отдельным файлом для каждой нитки.


а вы ещё и отдельный файл для каждой нити делаете? а что вы делаете, когда этих нитей >100 но каждая из них какюу-нибудь фигню для плюёт в лог?
и какже вы потом их мержите, или поведение одной нитки у вас никогда не зависит от поведения(а значит и описания их работы в логе) от других?
Re[14]: Насколько "вредно" использование singleton?
От: enji  
Дата: 27.07.10 14:17
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, enji, Вы писали:


E>>первый — это класс LogStream, второй — интерфейс обработчика, класс LogMessage и функция registerProcessor()


I>Это уже слишком много


Ну тогда готов выслушать ваши предложения по поводу системы логирования

Мой подход таков:
// файл log.h

class LogStream
{
public:
  LogStream(const std::string &what, int severity);
  ~LogStream();
  
  LogStream& operator<<(...);
  ...
};

// файл logRel.h

struct Message
{
  time time;
  std::string what;  
  int severity;
  std::string msg;
};

struct IProcessor
{
  virtual void doLog(const Message &m) = 0;
};

void registerProcessor(const std::string &what, int severity, IProcessor *proc);

// файл log.cpp

struct LogData
{
  void reigster(const std::string &what, int severity, IProcessor *proc);
  void doLog(const Message &m);
  static LogData& get();
};

LogStream::~LogStream()
{
  Message m;
  ...
  LogData::get().doLog(m);
};

void registerProcessor(const std::string &what, int severity, IProcessor *proc)
{
  LogData::get().registerProcessor(what, severity, proc);
}


E>>ИМХО, таскать во многих объектах такую ссылку нифига не удобно.


I>Конечно неудобно, но это не значит, что для решения этой проблемы нужно создавать синглтон.


А что нужно создавать? Неужели вы реально хотите таскать ссылку на систему логирования через всю программу?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[14]: Насколько "вредно" использование singleton?
От: blackhearted Украина  
Дата: 27.07.10 14:22
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:


I>>>А как можно сделать "создаёт нужную категогрию логирования " без зависимости от системы логирования ?


B>>вызывая

B>>
B>>logSingleton.createCategory("someString");
B>>


B>>C таким подходом вообще всё логирование — это зависимость от системы логирования.


I>В данном случае ты проблему зависимости решил с помощью синглтона.


I>Это именно тот случай, где синглтон не стоит применять.


Ваш рецепт логирования на плюсах?
Re[15]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 14:48
Оценка:
Здравствуйте, blackhearted, Вы писали:

I>>В данном случае ты проблему зависимости решил с помощью синглтона.


I>>Это именно тот случай, где синглтон не стоит применять.


B>Ваш рецепт логирования на плюсах?


Как минимум service locator
Re[15]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 14:49
Оценка:
Здравствуйте, enji, Вы писали:

I>>Конечно неудобно, но это не значит, что для решения этой проблемы нужно создавать синглтон.


E>А что нужно создавать? Неужели вы реально хотите таскать ссылку на систему логирования через всю программу?


Не конечно. И синглтон тоже не нужен
Re[16]: Насколько "вредно" использование singleton?
От: blackhearted Украина  
Дата: 27.07.10 14:51
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:


I>>>В данном случае ты проблему зависимости решил с помощью синглтона.


I>>>Это именно тот случай, где синглтон не стоит применять.


B>>Ваш рецепт логирования на плюсах?


I>Как минимум service locator


Не тяжеловато-ли будет в нагруженном сервере его использовать для логирования?
Re[17]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 15:03
Оценка:
Здравствуйте, blackhearted, Вы писали:

B>>>Ваш рецепт логирования на плюсах?


I>>Как минимум service locator


B>Не тяжеловато-ли будет в нагруженном сервере его использовать для логирования?


Что ты понимаешь под словами "service locator" ?

Нужно один раз на объект получить ссылку на логгер. Если это можт повалить нагруженый сервер, то сдаётся проблема где то в другом месте.
Re[18]: Насколько "вредно" использование singleton?
От: blackhearted Украина  
Дата: 27.07.10 15:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:


B>>>>Ваш рецепт логирования на плюсах?


I>>>Как минимум service locator


B>>Не тяжеловато-ли будет в нагруженном сервере его использовать для логирования?


I>Что ты понимаешь под словами "service locator" ?


I>Нужно один раз на объект получить ссылку на логгер. Если это можт повалить нагруженый сервер, то сдаётся проблема где то в другом месте.


Я понимаю это так же как и википедия

The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator" which on request returns the information necessary to perform a certain task.


Не вижу преимущества central registry перед singleton.
Re[19]: Насколько "вредно" использование singleton?
От: blackhearted Украина  
Дата: 27.07.10 15:10
Оценка:
I>>Нужно один раз на объект получить ссылку на логгер. Если это можт повалить нагруженый сервер, то сдаётся проблема где то в другом месте.

B>Я понимаю это так же как и википедия


B>

B>The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator" which on request returns the information necessary to perform a certain task.


B>Не вижу преимущества central registry перед singleton.


Т.е. разницы между

Locator locator;
Logger* logger = locator.getLogger(className);


перед

LogSystem ls = LogSystemSingleton.getInstance();
Logger* logger = ls.getLogger(className);
Re[11]: Насколько "вредно" использование singleton?
От: Тот кто сидит в пруду Россия  
Дата: 27.07.10 15:19
Оценка:
Здравствуйте, Sni4ok, Вы писали:

ТКС>>Если и это не устраивает, целесообразнее будет завести отдельный сервис логгирования, а не мучатся с отдельным файлом для каждой нитки.


S>а вы ещё и отдельный файл для каждой нити делаете?


Нет конечно. Но тут кто-то предлагал.

S> а что вы делаете, когда этих нитей >100 но каждая из них какюу-нибудь фигню для плюёт в лог?

S>и какже вы потом их мержите, или поведение одной нитки у вас никогда не зависит от поведения(а значит и описания их работы в логе) от других?

Не ко мне вопрос.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[19]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 18:48
Оценка:
Здравствуйте, blackhearted, Вы писали:

B>

B>The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator" which on request returns the information necessary to perform a certain task.


B>Не вижу преимущества central registry перед singleton.


ну так service locator не сводится к central registry.

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

В случае с синглтоном всё это отсутствует.

сам central registry и будет синглтоном, но кроме него не будет никаких других синглтонов, ни для лога, ни для чего еще.

Не зря в букварях по паттернам сообщается что использовать синглтон для управления зависимостями крайне некузяво

Есть еще более сильная вещь, dependency injection, но на с++ я видел такое только для COM-объектов.
Re[20]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.07.10 18:55
Оценка:
Здравствуйте, blackhearted, Вы писали:

B>>Не вижу преимущества central registry перед singleton.


B>Т.е. разницы между


B>
B>Locator locator;
B>Logger* logger = locator.getLogger(className);
B>


B>перед


B>
B>LogSystem ls = LogSystemSingleton.getInstance();
B>Logger* logger = ls.getLogger(className);
B>


Локатор дает доступ к самым различным сервисам, а не только к логгеру.

Логгер — это т.н. сквозной функционал, ты что, будешь для каждого такого сервиса синглтон городить ?

Используя dependency injection у тебя получится примерно так

classA::classA(ILogger* pLogger)
{
  this->pLogger = pLogger;
}


или так

classA::SetLogger(ILogger* pLogger)
{
  this->pLogger = pLogger;
}


И это будет работать _само_
Re[20]: Насколько "вредно" использование singleton?
От: enji  
Дата: 28.07.10 05:48
Оценка:
Здравствуйте, Ikemefula, Вы писали:

B>>Не вижу преимущества central registry перед singleton.


I>ну так service locator не сводится к central registry.


I>Преимущетсво локатора оного в слабой связности, тестируемости, прозрачности, реюзабельности кода. заплатить за это нужно зависимостью от одного конкретного интерфейса и интерфейсом самого локатора.


I>В случае с синглтоном всё это отсутствует.


I>сам central registry и будет синглтоном, но кроме него не будет никаких других синглтонов, ни для лога, ни для чего еще.


Ну т.е. вместо 20 несвязанных друг с другом синглтонов, каждый из которых ничего не знает о других, будет 1 мегасинглтон, который знает и о системе логирования и о загрузке данных через интернет (где-то выше мелькал пример) и о драйверах оборудования, ... Получается этот мегасинглтон заточен под конкретный проект, перетащить его в другой проект в принципе невозможно.

Или же этот реестр будет хранить что-то вроде void*, а затем будет иметься кошмарный интерфейс вида reestr::get<LogSystem>()->log("bla bla")

И чем такой подход лучше?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[6]: Насколько "вредно" использование singleton?
От: sidorov18 США  
Дата: 28.07.10 07:46
Оценка:
Здравствуйте, szag, Вы писали:

S>Здравствуйте, sidorov18, Вы писали:


S>>У меня, например, синглтоном класс лог.

S>>А еще есть класс-синглтон, который контент из нета качает и парсит в свои структуры.

S>всегда может понадобится второй лог и работа через несколько соединений. Чисто моё имхо, в идеальной программе сингелтонов быть не должно. Практически всегда может потребоваться вторая копия объекта и исправить это будет не так просто, как изначально отказаться от использования синглтонов.


Это зависит от того, как сделан синглтон, насколько его "синглтоновость" вшита в класс. И может решатся комментированием одной строчки или даже его можно сделать многофункциональым.
например:

template<typename T>
T& get_instance_singletone()
{
   static T t;//работу в многопоточной среде убираем для наглядности.
   return t;
}


или это уже не синглтон?


второй экземпляр может понадобится, а может и не понадобится.
Например есть COM класс, который должен быть синглтоном. и за последние пол года это не изменилось пока)
Синглтоном его делает своя фабрика. Как в этом случае избавится от синглтона? COM сервер — внепроцессный.
А чтобы его переделать в обычный класс, нужно закомментить одну строчку — DECLARE_CLASSFACTORY_EX(...) или добавить еще один класс, который будет от него наследоватся — если нужно 2 класса.
Re[21]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.07.10 09:00
Оценка:
Здравствуйте, enji, Вы писали:

E>Ну т.е. вместо 20 несвязанных друг с другом синглтонов, каждый из которых ничего не знает о других, будет 1 мегасинглтон, который знает и о системе логирования и о загрузке данных через интернет (где-то выше мелькал пример) и о драйверах оборудования, ... Получается этот мегасинглтон заточен под конкретный проект, перетащить его в другой проект в принципе невозможно.


Код конфгурации знает про всё в системе. Сам regisry вообще ни про что не знает.

этот мегасингтон перетаскивается на раз в другой проект.

E>Или же этот реестр будет хранить что-то вроде void*, а затем будет иметься кошмарный интерфейс вида reestr::get<LogSystem>()->log("bla bla")


Реестр будет хранить то, что в него напихал конфигуратор.

E>И чем такой подход лучше?


слабая связанность, теструемость, реюзабельность, прозрачность
Re[23]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.07.10 10:33
Оценка:
Здравствуйте, enji, Вы писали:

I>>Реестр будет хранить то, что в него напихал конфигуратор.


E>Ну и как напиханное получать?


Через публичный интерфейс.

I>>слабая связанность, теструемость, реюзабельность, прозрачность


E>Хорошо. Давайте на примере. Чем запись LogSystem::get() лучше reestr::get()->get<LogSystem>() ?


Давай, только посмотри мои примеры в этом топике, а то мне кажется ты не понимаешь то о чем я тебе говорю.

E>Как именно это улучшает:

E> — связность (ведь клиенты лога по прежнему должны иметь доступ к его интерфейсу + теперь еще и к интерфейсу реестра)?

При чем здесь лог твой ? Еть компонент например для рендеринга, который использует логирование.

вот этот компонент не должен иметь никаких лишних зависимостей, как система логирования и тд.

E> — тестируемость (ведь лог пишет в указанные ему обработчики, надо проверить взаимодействие класса и лога — просто создаем спец обработчик для тестов и анализируем, что ему пришло)?


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

E> — реюзабельность (система логирования вполне устоявшаяся штука, реюзается из проекта в проект; вы же предлагаете вместе с ней реюзать еще и реестр)?


Опять же речь про компонент, а не про твой лог.

Компонент должен быть реюзабельным и не зависеть от лога и тд.

E> — прозрачность (чем непрозрачна обычная система логирования, зачем привлекать еще и специальный реестр)?


Код использующий самые разные синглтоны непрозрачный.
Re[24]: Насколько "вредно" использование singleton?
От: enji  
Дата: 28.07.10 13:02
Оценка:
Здравствуйте, Ikemefula, Вы писали:

E>>Хорошо. Давайте на примере. Чем запись LogSystem::get() лучше reestr::get()->get<LogSystem>() ?


I>Давай, только посмотри мои примеры в этом топике, а то мне кажется ты не понимаешь то о чем я тебе говорю.


Да видел я их

E>>Как именно это улучшает:

E>> — связность (ведь клиенты лога по прежнему должны иметь доступ к его интерфейсу + теперь еще и к интерфейсу реестра)?

I>При чем здесь лог твой ? Еть компонент например для рендеринга, который использует логирование.


I>вот этот компонент не должен иметь никаких лишних зависимостей, как система логирования и тд.


Компонент для рендеринга, который использует логирование — он как получает ссылку на лог-систему? Ты где-то выше приводил пример — или через конструктор или через метод set_log
Ну т.е. если иметь пару десятков разных компонент, которым нужно логирование, то их надо переделать так, чтобы они имели ссылку на лог-систему и как-то ее устанавливать при их создании. Я правильно понял?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[25]: Насколько "вредно" использование singleton?
От: enji  
Дата: 28.07.10 13:08
Оценка:
Здравствуйте, enji, Вы писали:

E>Здравствуйте, Ikemefula, Вы писали:


E>>>Хорошо. Давайте на примере. Чем запись LogSystem::get() лучше reestr::get()->get<LogSystem>() ?


I>>Давай, только посмотри мои примеры в этом топике, а то мне кажется ты не понимаешь то о чем я тебе говорю.


E>Да видел я их


E>>>Как именно это улучшает:

E>>> — связность (ведь клиенты лога по прежнему должны иметь доступ к его интерфейсу + теперь еще и к интерфейсу реестра)?

I>>При чем здесь лог твой ? Еть компонент например для рендеринга, который использует логирование.


I>>вот этот компонент не должен иметь никаких лишних зависимостей, как система логирования и тд.


E>Компонент для рендеринга, который использует логирование — он как получает ссылку на лог-систему? Ты где-то выше приводил пример — или через конструктор или через метод set_log

E> Ну т.е. если иметь пару десятков разных компонент, которым нужно логирование, то их надо переделать так, чтобы они имели ссылку на лог-систему и как-то ее устанавливать при их создании. Я правильно понял?

вдогонку:

или же они должны зависеть от единственного синглтона reestr и брать лог-систему у него
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[25]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.07.10 13:38
Оценка:
Здравствуйте, enji, Вы писали:

E> Ну т.е. если иметь пару десятков разных компонент, которым нужно логирование, то их надо переделать так, чтобы они имели ссылку на лог-систему и как-то ее устанавливать при их создании. Я правильно понял?


да, один из способов это service locator — компонент вытягивает и инициализирует свои депенденсы сам. Компоненту нужно передать только указатель на интерфейс вроде IServiceLocator.

Второй способ — инжекция, компонент выставляет наружу методы для инициализации депенденсов, соответвенно в проекте нужен компонент для инжекции.

в каждом случае инициализация отделена от конфигурирования, конфигуратор знает всё про всех, а компоненты друг про друга ничего не знают, кроме интерфейсов.
Re[26]: Насколько "вредно" использование singleton?
От: enji  
Дата: 28.07.10 14:21
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>да, один из способов это service locator — компонент вытягивает и инициализирует свои депенденсы сам. Компоненту нужно передать только указатель на интерфейс вроде IServiceLocator.


I>Второй способ — инжекция, компонент выставляет наружу методы для инициализации депенденсов, соответвенно в проекте нужен компонент для инжекции.


I>в каждом случае инициализация отделена от конфигурирования, конфигуратор знает всё про всех, а компоненты друг про друга ничего не знают, кроме интерфейсов.


Идею я понял, спасибо за разъяснения.

Но все таки применительно к логу , ИМХО, нет особого смысла в этом. Библиотека логирования довольно устоявшаяся и простая штука и врядли когда-либо будет меняться. А за счет того, что всю реальную работу выполняют обработчики, которые можно подключать совершенно произвольно или не подключать вообще, зависимость от библиотеки логирования не препятствует тестированию или повторному использованию
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[27]: Насколько "вредно" использование singleton?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.07.10 14:41
Оценка:
Здравствуйте, enji, Вы писали:

E>Но все таки применительно к логу , ИМХО, нет особого смысла в этом. Библиотека логирования довольно устоявшаяся и простая штука и врядли когда-либо будет меняться. А за счет того, что всю реальную работу выполняют обработчики, которые можно подключать совершенно произвольно или не подключать вообще, зависимость от библиотеки логирования не препятствует тестированию или повторному использованию


В другом проекте может быть другая система логирования, а во время тестирования может понадобиться заменить логирование например заглушкой, что бы свести к минимуму затраты на логирование.
Re[28]: Насколько "вредно" использование singleton?
От: enji  
Дата: 29.07.10 07:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

С учетом того, что логирует не система логирования, а обработчики:

I>В другом проекте может быть другая система логирования,

другая система логирования = другие обработчики

I> а во время тестирования может понадобиться заменить логирование например заглушкой, что бы свести к минимуму затраты на логирование.

заглушка = отсутствие обработчиков

А вообще, хочется заменить систему логирования целиком — ну подключи не файл log.cpp, а совместимый по интерфейсу файл log2.cpp

Синглетон плох, если в одном проекте их понадобится два — скажем один компонент использует очень простое и быстрое логирование, а второй — наворочненное но медленное. Но чет как-то пока сложно представить, зачем это может понадобиться
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.