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

[WindWalker]

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

по мне так проще вместо создания "непоймикакогосингтона" написать как-нить так:

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

Вот пример. Есть базовый класс.

package {
	public class MyClass1 {		
		private static function $hello():void {
			trace("Hello from class 1");
		}

		public function hello() {
			$hello();
		}
	}
}

Решили переопределить метод:

package {
	public class MyClass2 extends MyClass1 {		
		private static function $hello():void {
			trace("Hello from class 2");
		}
	}
}

Ну и проверям:

new MyClass2().hello();

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

[Iv]

2morrowMan, здесь профессиональный форум и изначально я отношусь к любому как к коллеге, уважительно.
При этом не имеет значения уровень - что гуру, что начинающий, в моих глазах имеет одинаковый респект.
Но блин, есть же общепринятые нормы общения. Если высказываешься, будь готов аргументировать свою точку зрения. Я готов поспорить и с удовольствием откажусь от собственных заблуждений, если оппонент мне аргументированно докажет это. С удовольствием, подчеркиваю. Потому, что этот человек подымет мой проф уровень, за что ему респект и спасибо.
Но не все понимают и частенько весь их текст несет информации не более чем пук в воду. Это бесит.

[BlooDHounD]

Iv, я аргументировал. что у тебя вызвало вопрос, я не понимаю. извини, что не умею писать 10 кб текста неся при это одну единственную мысль: "ты привёл не правильные примеры использования синглтонов". ну не прозаик я. написал коротко и ясно. ты обиделся почему-то. извини.

WindWalker, я не понимаю зачем вы пытаетесь переопределить приватный, к тому же статический метод, не используя слово override. Может я не понимаю, но у меня в обоих случаях выводится: "Hello from class 1".

если вы хотели переопределить, то надо было написать так:

package {
	public class MyClass2 extends MyClass1 {		
		public override function hello():void {
			trace("Hello from class 2");
		}
	}
}

[WindWalker]

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

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

Чтобы показать, насколько негибкими являются статические методы.
override вообще нельзя писать одновременно со static (как я буквально только что выяснил ).

Может я не понимаю, но у меня в обоих случаях выводится: "Hello from class 1".

Вот-вот. Это и есть бага.

Преимущество синглтона в том, что он - экземпляр.
1. У него нормальные методы, которые можно переопределять (со статическими просто так не выйдет).
2. Он может имплементировать интерфейс (попробуйте сделать это со статическими методами).
3. В последствии мы можем отказаться от требования иметь только один экземпляр, и насоздавать их несколько.

[BlooDHounD]

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

Чтобы показать, насколько негибкими являются статические методы.
override вообще нельзя писать одновременно со static (как я буквально только что выяснил ).

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

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

Преимущество синглтона в том, что он - экземпляр.
1. У него нормальные методы, которые можно переопределять (со статическими просто так не выйдет).
2. Он может имплементировать интерфейс (попробуйте сделать это со статическими методами).
3. В последствии мы можем отказаться от требования иметь только один экземпляр, и насоздавать их несколько.

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

update:
забыл аргументировать первый пункт (специательно для Вани).
1. никакого преимущества.
так как Ваня описал выше, это класс который должен быть один одинёшеньки. наследование такого класса может привести к непредсказуемым последствиям. так как вполне логично, что и наследник будет выполнять схожие со стоим родителем задачи, их действия могут пересечься, что слегка нарушит всё логическое обоснование одиночки.

[miramax]

А я не люблю паттерны. =)
Раньше использовал синглтон только если в глобальной точке доступа необходимо было наследоваться или имплементировать какой-то интерфейс (например IEventDispatcher).
Потом отказался в пользу обыкновенных объектов находящихся в статических константах.
Стало проще жить =).

P.S. BlooDHounD, синглтон - интуитивно финальный класс, это все понимают. В первом пункте речь о наследовании полей самим синглтоном, т.е. о том из-за чего и я использовал его в начале.

[BlooDHounD]

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

P.S. BlooDHounD, синглтон - интуитивно финальный класс, это все понимают. В первом пункте речь о наследовании полей самим синглтоном, т.е. о том из-за чего и я использовал его в начале.

как это вытекает из написанного тут:

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

1. У него нормальные методы, которые можно переопределять (со статическими просто так не выйдет).

толи я идиот, толи вы невнимательно читали.

[miramax]

public class Singleton extend EventDispatcher{}

И класс Singleton имеет методы addEventListener, removeEventListener готовые для переопределения.

[BlooDHounD]

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

[WindWalker]

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

Ваш вариант реализации ничем не отличается, так как до самого синглтона, наследник тоже никак не дотянется, как и до приватного статического метода.

Лёгким движением руки класс RealSingleton переноситься в отдельный файл и делается публичным. И никто этого даже не заметит (даже поддельный Singleton. В худшем случае дописываем import).

Далее можно наследовать (если очень хочется).

Со статическими методами не всё так просто. Можно превратить их в public, но переопределять их всё равно не сможем.

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

У нас есть класс-посредник. Никто, кроме него, про синглтон не знает.
Вот в нём-то, если надо, и делаем необходимые изменения, чтобы первым создавался именно экземпляр наследника, а не родителя.

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

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

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

Не факт.
Пример с сетевым соединением как раз мне нравится.
Допустим, первоначально предполагалось, что соединение должно быть одно и только одно. Сделали синглтончик Connection.

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

И ещё не забываем, что у нас есть класс-посредник (в случае с соединениями например класс Request).
И про одиночку и его одиночество знает только этот посредник (да и то не всегда). Соответственно, и необходимые изменения (возможно, хотя и не всегда конечно) достаточно будет сделать только в нём.

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

Я могу привести пример, где такое наследование может пригодиться.
Опять же сетевое соединение. Опять же одновременно только одно.
Но!
Сперва пробуем SocketConnection, если обломались, то его убиваем и используем HTTPConnection.
Оба наследуются от некоего AbstractConnection.

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

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