Форум Flasher.ru - реализация паттерна singleton на AS3

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

- - реализация паттерна singleton на AS3 (http://www.flasher.ru/forum/showthread.php?t=109596)

Цитата:

Сообщение от 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();

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

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

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

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

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

Код:

package {

        public class MyClass2 extends MyClass1 {                

                public override function hello():void {

                        trace("Hello from class 2");

                }

        }

}

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Код:

public class Singleton extend EventDispatcher{}

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

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

Цитата:

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

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

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

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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