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

Пример 1.

Аркадная игра. Бегает мужичок, стреляет в монстряков, собирает бонусы.
У мужичка есть разные параметры: очки, здоровье, патроны, и всякие там ключи для открывания дверей.
Где будем это всё хранить?

Пример 2.
Есть 10 кнопочек, которые при нажатии должны издавать одинаковый звук. Разумеется, загружать 10 раз один и тот же звук глупо - достаточно один раз и его всегда использовать.
Конечно, можно его впихнуть в какую-нибудь статическую переменную.

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

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

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

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

Ок. Многие объекты (аптечки, коробки с патронами, двери, пульки, монстры) могут или изменять параметры человечка (добавить/убавить) или напротив их поведение будет зависеть от параметров человечка (откроется/не откроется, подберётся/останется).

Каким образом они будут получать к ним доступ?

Элементарно. Кнопочке добавляем переменную экземпляра: sound.
По умолчанию пихаем туда стандартный звук, который реализован как синглтон. При необходимости пихаем туда любой другой звук.

Я надеялся, что приведёте альтернативное решение.

Совершенно верно! Именно поэтому синглтон тут более удобен, так как в случае необходимости его всегда можно послать в топку без особых последствий. О чём я и твержу уже давно.
Например, делаем так, чтобы getInstance() возвращал не единствуенную и неповторимую дефалтную группу, а дефалтную группу текущего документа. Все изменения - внутри одного класса.

А вот если бы использовали статику - сели бы в колошу.

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

Потому что этот же звук может использоваться для других объектов.
Например, для чекбоксов.

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

Вот так и знал, блин, что так скажешь :)

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

То есть пихаем логику в контроллер? Разве так и положено?

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

Ну ты говоришь, что взаимодействие объектов в аркаде будет обрабатывать контроллер.

Вот, скажем, есть у нас в игре про мужичка два вида аптечек: одна увеличивает здоровье на 25 хп, но не более, чем до 100, вторая учеличивает на 100 хп, но не более, чем до 200. Если уже максимум хп, то аптечка не берётся.

Мужичок наступает на аптечку (кстати, кто определяет столкновение? по идее это тоже логика). Как происходит дальнейшая обработка?