в английской википедии, в статье про синглтон ( 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 программисты