Один единственный раз использовал и именно по этой причине :)

Хм... Всё чуть хуже, чем я думал. Вероятно WindWalker'у надо сказать, что синглтон - финальный :)

может закончим холивар? все равно ведь все останутся при своем!!! а за время пока вот тут идут дебаты, я открыл для себя паттерн "абстрактная фабрика", может еще по поводу него поспорим? ;)

Определённый интерфейс - это implements ISerializable, например.

Ок. Я книжку-то про паттерны так и не прочитал, так что каких-то ограничений могу и не знать. :)
Раз есть какие-то веские причины, чтобы он был всегда финальным - пусть будет финальным (кстати, какие именно причины?).

Но таки меняем пункт 1.
Синглтон может от кого-то наследоваться, переопределяя методы (в том числе вызывая старые методы через super()).
А со статическими методами возникнет ряд проблем...

-----------------------------

Последняя добавочка.

Я на самом деле использую и статические методы, и синглтоны.
И то и другое - для глобального доступа. Потому что глобальный доступ - это такой "черный ход", который зачастую позволяет сильно сократить путь.
Когда времени мало, а надо, чтобы какой-то очень мелкий объектик, обычно отвечающий за какую-то мелкую функцию, вдруг узнал что-то общее (например, громкость звука или url к сервлету) или даже вообще сделал что-то глобальное (например, какой-нить мелкий бонус вдруг взял да увеличил количество очков у игрока), и передавать это всё по цепочке не хочется - использую глобальный доступ.

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

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

Так статический метод только один: getInstance().
Пускай остаётся таким, какой он есть.

Я говорю про методы/поля самого экземпляра. Прекрасно переопределяются.

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

даже если вы вынесете синглтон в отдельный класс, то класс посредник уже нафиг не нужен, так как к нему будут иметь доступ все. наследовать его тем болие не надо. зачем? у нас же есть класс посредник мы может прям там написать.
это будет уже не сингтон. вся идеология нарушена. я тут описал: Ваш PS говорит о том, переопределять синглтон ваще нафиг не нужно. проще его изменить.

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

p.S: у нас кстати реализован ваш пример. конечно без сингтона. и уж тем болие без статиков.

Ну вот этот метод будет всегда возвращать инстанцию класса в котором он объявлен.

между прочим, с наследованием класса, ты наследуешь все его методы и свойтсва (условно можно считать этот набор интерфейсом класса), а так же и все его интерфейсы.

Блин, точно :)
Всё, понял-отстал!

Наверное потому, что экземпляр класса Request (или одного из его потомков) и экземпляр класса Connection - это немного разные сущности и не стоит их мешать в одну кучу.

Connection - синглтон, Request - посредник.

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

То есть, вообще говоря, синглтон тут вовсе даже и не главный получается :)
Просто - как одна из возможностей реализации.

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

Да у меня тоже реализован. Причём несколько раз :)
Но вот щас не могу вспомнить подробности, а исходников под рукой нет.