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

[etc]

WindWalker получает плюс. Холивар холиваром, а на личности переходить нельзя.

[NePridymal]

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

Ну а мне в моем коде (на второй странице) можно показать косяки? Если уж говоришь - то делай.

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

[Iv]

Нет косяков у тебя. Но предложенный тобой вариант есть в обсуждении синглтона: http://yarovoy.com/2007/10/24/single...ctionscript_3/
Там-же к коментах есть и мой:

public static const INSTANCE : Singleton = new Singleton();
public function Singleton () {
	if (INSTANCE) throw new Error("**Error** - singleton. Сonstructor is locked.");
}

С подробным описанием того, какие недостатки других синглетонов в нем устранены.

[BlooDHounD]

абсолютно неудобная. если она используется больше чем в одном месте.

[terbooter]

Iv, спасибо за разъяснения.
Еще два вопроса.

1) Какой-нибудь конкретный пример "правильного" применения синглтона в АС3

2) Присоединяюсь к

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

...
Вот если есть нечто глобальное, что влияет на всё приложение в целом, то каким образом это лучше всего реализовать?

Пример с опциями уже приводил.
Другой пример - имя игрового аккаунта (в мультиплеерной) или игрового профиля (в сингплеерной) игре. Показывать и использовать надо в разных местах. А хранить надо в одном.
Каким образом это лучше всего реализовать?

[Iv]

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

Примеы:

Сокет-коннектор.
приложение устанавливает сокет-соединение с сервером. Из разных частей приложения вызываются команды коннектора. Команды организуются в очередь FIFO и производится контроль ответов сервера.
В этой ситуации синглетон - верное решение. Его задачи - не дать ошибиться программеру случайно создав второй экземпляр и не производить постоянную проверку на наличие коннектора перед вызовом его метода.

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

Как видите, синглетон (он переводится как одиночка) - это такой класс, у которого может быть один и только один экземпляр.
Его одиночество как проверочное действие: если теоретически может быть несколько экземпляров, то это не синглетон.

[BlooDHounD]

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

Сокет-коннектор.
приложение устанавливает сокет-соединение с сервером. Из разных частей приложения вызываются команды коннектора. Команды организуются в очередь FIFO и производится контроль ответов сервера.
В этой ситуации синглетон - верное решение. Его задачи - не дать ошибиться программеру случайно создав второй экземпляр и не производить постоянную проверку на наличие коннектора перед вызовом его метода.

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

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

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

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

var s:Singletone = Singletone.getInstance();
var c:Class = s.getClass();

обычно в игре таких строк около сотни. я предпочитаю написать:

var c:Class = StaticClass.getClass();

[WindWalker]

Вот бредятина-то.

Вместо одного "пусть неправильно зато писать мало" предлагается "ещё более неправильно, зато писать ещё меньше".

[Iv]

BlooDHounD,
собственно в рассуждениях ты допускаешь типичную ошибку трактовки синглетона.
Метод доступа к данным (статические методы или через экземпляр полученный через getInstance) значения не имеют.
Ты пытаешься оценивать синглетон в качестве способа глобального доступа, что в корне неверно. Синглетон не для этого предназначен.
Ну как сравнивать молоток с микроскопом.

В принципе, у синглетона может и не быть метода getInstance (или он может быть приватным) и у экземпляра такого класса снаружи не будет торчать ни одного публичного метода экземпляра. Только статики, перенаправляющие задачи на экземпляр.
Синглетон же обеспечивает наличие единственного и неповторимого экземпляра класса, с помощью которого выполняются конкретные действия.

[WindWalker]

Хмм... А если тогда реализовать Синглтон следующим образом:

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

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

Сейчас попробую это в виде кода оформить...