BlooDHounD,
1) Один из наиболее обсуждаемых моментов в этом топике, хорошо ли делатьт синглтон с глобальным доступом.
Оказывается что не просто хорошо, а это его прямая цель.
Не понял только что именно зачем?

2) Как это противоречит сути синглтона?

3) Вы читали или смотрели книгу Гамма и др Design Patterns http://www.amazon.com/gp/reader/0201...pt#reader-link

1. как-то плохо вы читали. два самых обсуждаемых это: "нафига его ваще юзать?", "блуд - лучшее средство для похудения! пообщайся с блудом и сблевони!"
2. выше написано. перечитайте внимательнее.
3. а вычитали сравнительные анализы синглтона и статиков? мыслить надо не чужими мозгами, типа Гамма, а задачами, основываясь на опыте старых дядек (у которых мозги давно зачерствели, поэтому их по увольняли с работы и они сидят и пишут фолианты текста, ведь кушать хочется :) ) , но не повторяя их ошибок, в которых они всё равно никогда не признаются.

Эх, выходит не читали...
Пойду сблевану -)

не делайте выводов, от которых вам же и приходится потом блевать :)

Если вы продолжите общаться в таком ключе, то плюсы вам гарантированы.

Самый обсуждаемый здесь момент: "что такого хорошего есть в синглтоне, ради чего стоит писать на целых 14 символов больше".
----------------------------------------

Вот ситуация, когда Одиночка нужен именно как Одиночка.

Для создания объекта B нам необходимо, чтобы уже существовал объект A.
Например, B создаётся с помощью A. Либо между ними есть какая-то связь, которая должна быть прописана сразу в момент создания.
Конкретика не важна, главное, что для создания B обязательно требуется, чтобы уже существовал A.

Но и для объекта C тоже необходимо существование A, причём того же самого. А ещё для D и E.
И создание объектов B, C, D и E раскидано по разным классам. Причём заранее неизвестно, в каком именно порядке они будут создаваться в процессе выполнения.

Вот тут-то как раз и надо, что A был Одиночкой. Когда он требуется в первый раз - создаётся. Когда требуется снова - используется уже созданный объект.

Хороший пример такой ситуации пока привести не могу. Пока есть только неудачный пример и поэтому я его приводить не буду :)

а передать всем этим объектам его в конструкторе никак нельзя?

+ к этому что не уверен что объектам B, C, D, ... нужен именно конкретный эземпляр. а если нужен конкретный, то зачем вообще экземпляр? не проще ли статическими методами и свойствами обойтись.

Терпеть немогу абстрактные рассуждения. Когда ты понимаешь о чем говоришь, ты сможешь объяснить на пальцах своей 70-ти летней бабушке суть и принципы концепции. Прочитал 9 страниц темы и так и не нашел конкретной, годной проблемы, где синглтон был-бы максимально уместен и его применение обуславливалось не "а я паттерны знаю!" а логичным и интуитивно понятныи решением. Насколько я помню в Cairngorm используется сингтон. Там он используется для удобства организации приложения и именно для глобального доступа к необходимой информации. Приведу пример как я это понимаю: Есть магазин. Есть у пользователья шопинг карт. Нам необходимо гарантировать, что шопинг карт у пользователя один, т.к. в других случаях может случится жестокий конфуз. Глобальный доступ при этом будет крайне удобен и почему это относят к минусам непонятно. Никаких классов B C D E F G, для которых необходим класс A, наследованный от подкласса Z.. заметьте.

Можно, разумеется.
Но прежде, чем передавать, нужно убедиться, что он существует.

Опять двадцать-пять. Цикл замкнулся, начинаем новую итерацию обсуждения :)

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

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

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

Что применять в конкретном случае, зависит от конкретной ситуации.

------------
P.S.
Никто не запрещает вообще всё приложение делать статикой.
Кому вообще нужны эти экземпляры?
Сделать один-единственный класс Application, который рулит всем, и в нём только статические переменные и методы. Всё остальное - объекты встроенных классов.
Лепота!
Назад - к истокам!