в английской википедии, в статье про синглтон ( http://en.wikipedia.org/wiki/Singleton_pattern )
есть пяток ссылок ([1]-[6], http://en.wikipedia.org/wiki/Singleton_pattern#cite_note-0) на статьи в которых говорится что синглтон это антипаттерн

так например пишут что синглон это не ООП, а замена глобальных переменных на глобальные функции,
что синглтон реализует "i know where you lives" антипаттерн, и повышает число скрытых зависимостей

/discuss

В общем случае наверное да, но есть ситуации, в которых это не так.
Я для себя выработал такое правило: объект может быть глобальным, только если его состояние не изменяется или для приложения не важно его состояние, например логгер и стандартные потоки ввода вывода, у них есть состояние, но как правило, приложению фиолетово, что выводили в лог или в поток минуту назад. 
Сам подумай, передавать в каждый объект указатель на std::cout или %loggername% - глупо.

Ссылки на высказывания людей с сомнительным авторитетом. Андрей Александреску около 30-и страниц этому шаблону проектирования, а Алексу Миллеру (кто это такой вообще?) вдруг взбрело в голову что это зло. Бегу удалять синглтоны  
Разумеется не надо строить свой код на одних синглтонах, но есть ситуации когда без него никак. Тот же логер, настройки и многое другое.

Это сообщение отредактировал(а) azesmcar - 5.8.2009, 10:31

Lazin, std::cout  - не синглтон. это обычная глобальная переменная. и это часть стандартной библиотеки
у std::cout есть состояние, оно изменяется манипуляторами и флагами.

но допустим, логгер может быть синглтоном, а все остальное - не может. значит синглтон плох, а логгер - это исключение из правила?

В принципе в приложении должен быть только один синглетон - приложение.   
А вот решение проблемы синглетонами - зло.

Добавлено @ 10:32

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


Это сообщение отредактировал(а) mes - 5.8.2009, 10:34

В идеале - да.  

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

cout можно рассматривать как singletone, вообще, я имел ввиду стандартные потоки ввода вывода в общем


да, но если не пользоваться манипуляторами(или правильно ими пользоваться), то иногда можно считать что его нет  

Что за странная постановка вопроса? Даже GOTO не является безусловным злом. "Все есть яд и все есть лекарство". Просто голову нужно применять почаще.
Насчет приложения. Допустим, у меня есть куча объектов типа логгер (т.е. ровно один инстанс на сесссию). Какой-нибудь менеджер событий, очередь чего-нибудь глобальная, регистраторы разные, да мало ли. И что, по вашей логике, я их все из объекта-пртложения должна получать? И во что тогда объект-приложение превратиться? При том, что информация о как минимум половине этих объектов ему нафиг не нужна для нормальной жизни. Наоборот, преимущество синглетона в том, что он ни от кого не зависит и гарантирует единственность. Более того, семантика синглетона прекрасно расширяется на более сложные случаи, например, один экземпляр в потоке, или один экземпляр в документе, причем ни поток ни документ совершенно не должны знать об этих конкретных объектах. Т.е. это прекрасное средство для устранения лишних зависимостей.

Так что я синглетоны люблю. Но пользоваться ими надо не бездумно. Как и всем остальным, впрочем.

Earnest

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

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

если объекту не надо с чем-то взаимодействовать - то он не должен об этом знать, а если надо - это должно быть написано в интерфейсе объекта

Добавлено через 13 минут и 52 секунды

по моей логике должно быть
queue = new SomeQueue();
eventMan = new EventManager(queue);

если логгер не имеет состояния, то он вобщем-то и не объект, 
(у объекта есть внутреннее состояние, которое изменяется вызовом его методов)
и то как организован доступ к этому логгеру - через глобальную переменную, глобальную функцию или еще как - не важно.
для "объекта" без состояния нет разницы между
Logger log; ... log.write(...);
или
Logger::Instance().write(...);
или
Logger_write(...);

Это сообщение отредактировал(а) GoldFinch - 5.8.2009, 12:37

Earnest, в понятие паттерна синглетон входит случай лишь когда класс объекта,  сам регулирует единичное кол-во своих инстанций 
или когда некто внешний регулирует кол-во инстанций равным в нашем случае единице ?


Это сообщение отредактировал(а) mes - 5.8.2009, 12:55

mes, я и не имею в виду, что описанные расширения продолжают быть синглетоном. И потом, каноническое описание паттернов - это что евангелие новое? Смысл паттернов в том, чтобы дать пример логической организации кода и побудить к творчеству.  

А где гарантия того, что каждый второй клиент не начнет создавать свои очереди? Синглетон же гарантирует единственность. А что касается зависимостей - ты не прав. Нет там никакой зависимости на уровне реализации, во всяком случае можно так сделать. И вот это высказывание

более чем спорно. Для одного интерфейса может быть несколько реализаций: одни с зависимостями, другие без...
Кроме того, зависимости можно приблизительно учитывать как "прямого видение" определения класса \интерфейса \ функции. Так что когда зависимости только в реализации - их безусловно меньше.

Ну вот взять тот же логгер. Допустим у нас есть реальный Logger, с записью куда-нибудь и отсылкой нотификейшенов на e-mail и есть FakeLogger - для тестов. Работаем с логгером мы только через ILogger. Синглетон в чистом виде - явно не пойдёт. Нужна какая-то фабрика логгеров. Она же управляет временем жизни. И вообще созданием подобных объектов должны управлять DI-фреймворки  Синглетон - это костыль. Но зачастую приемлемый. Всему своё место и место каждой вещи под солнцем 

ох уж эти enterprise программисты  

По моему тут больше подойдет препроцессор #ifdef _DEBUG. Зачем нагружать программу фабрикой логеров для тестирования?

как вариант логгер который пишет plain text, логгер который пишит в xml формате или логгер который шлет все на мыло или еще куда

Добавлено через 4 минуты и 40 секунд

офтоп небольшой  
PocoCapsule например, больше не встречал готовых реализаций DI\IoC

Такое я бы реализовал передав ему аргумент writer какой нибудь, создать единый интерфейс для logwriter -а, наследовать от него xmlWriter, mailWriter и plainWriter например...а дальше так

ну или что-то наподобие этого. В коде можно будет различать случаи, когда нужно послать на мейл или вывести в log file.

Почему я не имею права запускать юнит-тесты на релизе?! Ещё и пересобирать.. Не, не хочу 


Вопрос, как таковой, не имеет отношения к С++ (точнее так - отношениее имеет, не имеет прямой привязки), так что...


1. В твоём примере полиморфизм не сработает - ты передаёшь объект по ссылке.
2. У тебя просто writer выполняет то, что я называл логгером.  Просто лишний уровень абстракции, но проблему создания объектов (сейчас ты их создаёшь заново при каждом вызове) это не решает.


Да-да, мы такие  Lazin, прости, но "с волками жить - по волчьи выть", как говорится  

Я думал речь идет о простом тестировании, но название препроцессора всегда можно изменить  
#ifdef UNIT_TEST или как там? Компилятор что-то там определяет точно.


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


так например.


Ну это я для примера написал, разумеется это не идеальный код, я саму идею имел ввиду. А кстати фабрика логеров это тоже лишний уровень абстракции.

Это сообщение отредактировал(а) azesmcar - 6.8.2009, 09:41

azesmcar, статический полиморфизм  - он статический, а надо, чтобы в ран-тайме можно было дать объекту логгер, обычный, продвинутый, или Null-логгер.
фабрика - это не уровень абстракции, а вспомогательный объект\класс, не влияющий на абстракцию того что она производит
объекты же не знают как и произвели  - просто создали, создали на фабрике или клонировали

Добавлено @ 10:59
azesmcar, а юнит тест это


Это сообщение отредактировал(а) GoldFinch - 6.8.2009, 11:00

Кто это так решил что надо? Я писал как раз о том, чтобы сделать это во время компиляции а не в рантайме, потому как не увидел смысла оставлять это на рантайм.


Да, но уровень абстракции нужен для работы фабрики.


Я знаю что такое юнит-тест. Что ты этим хотел сказать? Студия насколько я помню при генерации шаблона юнит тестов определяет какие-то конкретные макросы, можно использовать их или же определить свой собственный в настройках проекта в конце концов.

Это сообщение отредактировал(а) azesmcar - 6.8.2009, 11:07

По контексту обсуждаемого поста это не следовало. 

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

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

Это сообщение отредактировал(а) mes - 6.8.2009, 12:42

вот тут полиморфизма вообще нет.


Это сообщение отредактировал(а) GoldFinch - 6.8.2009, 12:49

это тебе так кажется. Это статический полиморфизм.

Это сообщение отредактировал(а) azesmcar - 6.8.2009, 12:50

fixed.

Добавлено через 33 секунды

было бы 
typedef ... logger_t;
...
logger_t::Instance()->write(...);

был бы полиморфизм.

хотя совсем не понятно, почему не просто 
logger_t::write(...);
(то что используется вызов метода по указателю, ->write(...); могло бы использоваться для виртуального метода, но это же не тот случай)

Добавлено через 2 минуты и 59 секунд
какбэ запись
  Logger<XMLWriter>
совершенно эквивалентна
 Logger_XMLWriter

а вот
  template<typename W> Logger<W> 
это совсем другое

что такое logger_t??? Куда он пишет и как дать понять куда я хочу писать? В XML Или в Plain text?


Каким образом вызов метода по указателю связан с виртуальным методом?

Но я как раз хочу сказать что динамический полиморфизм тут совершенно не нужен (ну или я не понял зачем он нужен, может у автора есть причина). 

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

Добавлено @ 13:04
Ну а вообще мне кажется, что в Вашем споре между  GoldFinch и  azesmcar, каждый спорит о своем..
Неплохо бы прояснить в чем суть то спора 


Это сообщение отредактировал(а) mes - 6.8.2009, 13:11

ну вообще тема про синглтоны

я не понял чем мой вариант отличался от "совсем другого"?


Я и сам не знаю 

azesmcar, а зачем объекту надо решать, кто куда ему будет писать? это уже много обязанностей, когда объект и основную работу выполняет и решает куда ему лог писать.
другое дело, что объекту нужен логгер для логов - ему дают логгер
(не каждый объект должен вести логи)
а вот нужно вести лог вообще, или в какой файл или не файл этот лог должен вестись - решает тот кто объект создает.
если лог не нужен, объекту дают null-логгер который ничего не делает, если нужно писать в файл или в сокет дают соответствующий логгер.

а статически или динамически - другой вопрос, будет это
    class Foo {
       Foo(ILogger* log) 
       ... 
    };
или
    template<typename LOG>
    class Foo { 
        Foo(LOG& log) 
        ...
    };
или
    template<typename CFG>
    class Foo { 
        Foo(CFG::logger_t log) 
        ...
    };

Добавлено через 1 минуту и 38 секунд

там что класс Writer жестко задан, и его никак не поменять

template<typename W> Logger<W>
Как ты будешь использовать этот класс?

не так что ли?

azesmcar, я имел ввиду
  template<typename W>
  ...
  {
     Logger<W>::write("text");
  }

и

  ...
  {
     Logger<ConcreteWriter>::write("text");
  }

это ведь разные вещи?

как например
  AbstractFoo* foo;
  foo->write("text");
и 
  ConcreteFoo* foo;
  foo->write("text");

Где-то его все равно надо будет конкретизировать. Я показал именно конкретизированную часть, хочешь передавай конркетный врайтер в функции main, какая разница. Это решается в зависимости от требований.