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

[BlooDHounD]

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

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

как не называй, а сиськи от этого лучше не станут. в этом прмиере (http://www.flasher.ru/forum/showpost...1&postcount=53) у вас нет таких страшных названий. мы обсуждали его на сколько я помню. у вас тут чистый синглтон ради синглтона.
о чём я повторяю уже 5 постов подряд. в этой конструкции нет смысла вовсе.

То есть, вообще говоря, синглтон тут вовсе даже и не главный получается

ага. собственно я и говорю что синглтон нафиг не нужен. применение класа посредника совершенно не связано сингтонам. и как его реализация она не подходит.

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

нууу .. вообще в "ООПешном понимании" класс тоже тип. от сюда я думаю вывод понятен.

Да у меня тоже реализован. Причём несколько раз

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

[WindWalker]

у вас тут чистый синглтон ради синглтона.

Это был всего лишь один из вариантов реализации.
1. без использования публичных статических методов вообще.
2. с возможностью быстро и безболезненно заменить синглтон на что угодно другое.
Сам синглтон там выполняет то дело, которое у него лучше всего получается: строго блюдёт своё одиночество.

нууу .. вообще в "ООПешном понимании" класс тоже тип. от сюда я думаю вывод понятен.

Ага. А ещё есть такое понятие, как совместимость типов.
Чтобы класс был совместим с интерфейсом, он должен его реализовывать.
И статические методы тут явно не при делах (хотя в AS2 с помощью хаков можно было добиться и такого).

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

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

[WindWalker]

О, вспомнил, из-за чего я разочаровлся в static'ах.
Класс ExternalInterface.
Используется для связи с неким внешним самописным приложением (далее - wrapper).

Так как часто приходиться тестировать флешку вне wrapper'а, то хочется сделать заглушку-эмулятор StubExternalInterface, который эмулирует поведение wrapper'а.
Как это сделать красиво, без "слабой" типизации?

[BlooDHounD]

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

Это был всего лишь один из вариантов реализации.
1. без использования публичных статических методов вообще.
2. с возможностью быстро и безболезненно заменить синглтон на что угодно другое.
Сам синглтон там выполняет то дело, которое у него лучше всего получается: строго блюдёт своё одиночество.

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

[WindWalker]

1. а причём тут публичные статичные методы? мы о них ваще ни разу не упоминали.

А при том, что обычно зовут getInstance() или что-нибудь подобное.
В моём примере этого нет. Используются обычные конструкторы.

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

Вдохни, выдохни, успокойся.
А потом скажи: что такое синглтон и для чего он служит?

Можешь ещё поправить реализацию обёртки, коль видишь там кривости.

[terbooter]

Открываю я книжку GoF:

Паттерн Singleton
Назначение:
Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа
...
Применимость:
Используйте паттерн Одиночка, когда:
* Должен быть ровно один экземпляр некоторого класса, легко доступный всем клиентам;
* единственный экземпляр должен расширяться путем порождения подклассов, и клиентам нужно иметь возможность работать с расширеным экземпляром без модификации своего кода.

Из этого делаю выводы (чистое ИМХО без всяких наездов):
1) Реализация глобального доступа одно из назначений синглтона.
Вот в этой книжке есть примеры для АС (Менеджеры звука, загрузки и тд):

Advanced ActionScript 3 with Design Patterns, 1/e
By Joey Lott, Danny Patterson
The Singleton design pattern is used to limit a class to one instance and provide global access to that instance

2) Синглтон не финальный класс.

[BlooDHounD]

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

Открываю я книжку GoF:
Из этого делаю выводы (чистое ИМХО без всяких наездов):
1) Реализация глобального доступа одно из назначений синглтона.
Вот в этой книжке есть примеры для АС (Менеджеры звука, загрузки и тд):
2) Синглтон не финальный класс.

1. зачем?
2. он перестанет быть одиночкой. это противоречие самой сути синглтона.

[WindWalker]

Классов может быть много, а экземпляр - один.

Это, кстати, куда интересней задачка.

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

[BlooDHounD]

ага только она уж очень не нужна

[WindWalker]

Ну это смотря у кого какие потребности.

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

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