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

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

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

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

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

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

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

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

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

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

Открываю я книжку GoF:
Из этого делаю выводы (чистое ИМХО без всяких наездов):
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,
1) Один из наиболее обсуждаемых моментов в этом топике, хорошо ли делатьт синглтон с глобальным доступом.
Оказывается что не просто хорошо, а это его прямая цель.
Не понял только что именно зачем?

2) Как это противоречит сути синглтона?

3) Вы читали или смотрели книгу Гамма и др Design Patterns http://www.amazon.com/gp/reader/0201...pt#reader-link

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

Эх, выходит не читали...
Пойду сблевану -)

не делайте выводов, от которых вам же и приходится потом блевать :)

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

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

Вот ситуация, когда Одиночка нужен именно как Одиночка.

Для создания объекта B нам необходимо, чтобы уже существовал объект A.
Например, B создаётся с помощью A. Либо между ними есть какая-то связь, которая должна быть прописана сразу в момент создания.
Конкретика не важна, главное, что для создания B обязательно требуется, чтобы уже существовал A.

Но и для объекта C тоже необходимо существование A, причём того же самого. А ещё для D и E.
И создание объектов B, C, D и E раскидано по разным классам. Причём заранее неизвестно, в каком именно порядке они будут создаваться в процессе выполнения.

Вот тут-то как раз и надо, что A был Одиночкой. Когда он требуется в первый раз - создаётся. Когда требуется снова - используется уже созданный объект.

Хороший пример такой ситуации пока привести не могу. Пока есть только неудачный пример и поэтому я его приводить не буду :)

а передать всем этим объектам его в конструкторе никак нельзя?

+ к этому что не уверен что объектам B, C, D, ... нужен именно конкретный эземпляр. а если нужен конкретный, то зачем вообще экземпляр? не проще ли статическими методами и свойствами обойтись.

Терпеть немогу абстрактные рассуждения. Когда ты понимаешь о чем говоришь, ты сможешь объяснить на пальцах своей 70-ти летней бабушке суть и принципы концепции. Прочитал 9 страниц темы и так и не нашел конкретной, годной проблемы, где синглтон был-бы максимально уместен и его применение обуславливалось не "а я паттерны знаю!" а логичным и интуитивно понятныи решением. Насколько я помню в Cairngorm используется сингтон. Там он используется для удобства организации приложения и именно для глобального доступа к необходимой информации. Приведу пример как я это понимаю: Есть магазин. Есть у пользователья шопинг карт. Нам необходимо гарантировать, что шопинг карт у пользователя один, т.к. в других случаях может случится жестокий конфуз. Глобальный доступ при этом будет крайне удобен и почему это относят к минусам непонятно. Никаких классов B C D E F G, для которых необходим класс A, наследованный от подкласса Z.. заметьте.

Можно, разумеется.
Но прежде, чем передавать, нужно убедиться, что он существует.

Опять двадцать-пять. Цикл замкнулся, начинаем новую итерацию обсуждения :)

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

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

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

Что применять в конкретном случае, зависит от конкретной ситуации.

------------
P.S.
Никто не запрещает вообще всё приложение делать статикой.
Кому вообще нужны эти экземпляры?
Сделать один-единственный класс Application, который рулит всем, и в нём только статические переменные и методы. Всё остальное - объекты встроенных классов.
Лепота!
Назад - к истокам!

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

Пример 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, в теории красиво. А на практике - помойка.

неверно вы правы :( как все вокруг этого не замечают? срочно публикуйте статью во все журналы мира!

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

Терпят, куда деваться-то. Делают из одного класса три, а потом костылями и подпорками соединяют их обратно в кучу.

P.S.
Я что-то так и не понял твой рецепт, как же избавиться от этих навязчивых приглашений.
Просто это очень насущная проблема. Частенько доходило до того, что отдавал другой конторе заказ, потому что был по горло занят основной работой и колымом, который та контора спихнула на меня :)
И это ещё цветочки...

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