реализация паттерна singleton на AS3

[llllllllll]

Сообщение от Iv

Прелесть синглетона в том, что можно его быстро переделать в обычный класс и обратно.

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

[miramax]

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

P.S.
Хотя насчёт "расширенной одиночки" подозреваю, что тут всё довольно просто - кто раньше встал, того и тапки. Статическая переменная instance то одна для всех. Как только чей-то экземпляр туда засунули, все остальные автоматически идут лесом.

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

[divinus]

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

[WindWalker]

Сообщение от BlooDHounD

я то это понимаю. это и называется "определённый интерфейс". это пункт 2.

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

Сообщение от miramax

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

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

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

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

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

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

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

[miramax]

Сообщение от WindWalker

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

Сообщение от WindWalker

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

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

[WindWalker]

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

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

[BlooDHounD]

Сообщение от WindWalker

Ещё раз повторяю: у нас есть класс-посредник.

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

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

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

это будет уже не сингтон. вся идеология нарушена. я тут описал:

Сообщение от BlooDHounD

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

Ваш PS говорит о том, переопределять синглтон ваще нафиг не нужно. проще его изменить.

Но есть ощущение, что чисто статическими методами тут тоже не обойтись (точнее обойтись то можно, но выйдет некрасиво).

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

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

[miramax]

Сообщение от WindWalker

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

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

[BlooDHounD]

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

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

[WindWalker]

Сообщение от miramax

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

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

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

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

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

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

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

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

Сообщение от BlooDHounD

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

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

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

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