Какой тип должен возвращать метод, если он должен возвращать разные события (типы)

[Psycho Tiger]

А вот мне сразу не понравились эти ServerEvent. Я стараюсь проектировать приложение так, чтобы не зависеть от источника данных. Чего и Вам советую.

Парсер в свои объекты, которые отдаются на растерзание всем желающим? Или как ты делаешь?

@wvxvw, ну switch хренов в плане парсинга чего-то от сервера или другого источника данных, с этим я (месяца как 4 ) согласен. Ну, а в чем другом плох switch? Неужели нет для него той ниши, в которой он лаконичен? )

[GBee]

wvxvw, вы просто кладезь инфы :о), у меня вопросов кучка.

список классов-сообщений: MessageA, MessageB... MessageZ, все наследуются от Message
у каждого есть метод clone(from:XML):Message который читает содержание из потока и создают свою копию исходя из полученных данных. Прийдется создать по экземпляру (лишнему) каждого сообщения, но, я не думаю, что это прям такая нагрузка, зато удобно.

1) Можно, по идее вместо экземпляра класса, запихнуть классы?
2) Почему бы здесь не использовать Dictionary вместо Object для хранения? Чем Dictionary плох, просто в большинстве примеров на форуме юзают именно объекты в таких случаях.

Ну, а в чем другом плох switch?

Присоединяюсь к вопросу. Ну не считая еще того, что читаемость кода падает (именно в вашем примере).

[Psycho Tiger]

"Object" легче. Если нужен хэш по строкам — то незачем брать танк, надо взять самое минимальное, что удовлетворяет требованиям.

[GBee]

Хм, больше вопросов возникло
Зачем тогда Dictionary? Для хэша по всему остальному? И что значительно тяжелее? А кто быстрее?

[Psycho Tiger]

Есть функция getSize из flash.samples. Она покажет размер объекта в памяти =) Но внутренние ссылки туда попадают именно как ссылки, 4 байта. Она не рекурсивная, то есть.
Любой объект во флеше наследуется от Object. Даже Dictionary. Поэтому очевидно что Dictionaty тяжелее.
Dictionary может делать то, чего не может Object: принимать в качестве ключей элементы, отличные от строковых. В этом его главное предназначение. Вторичное - наличие weakReference,

[zhoran]

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

Я бы делал так:
список классов-сообщений: MessageA, MessageB... MessageZ, ...
у вас будет таблица, например:

private static const MESSAGES:Object = { messageA: new MessageA(), messageB: new MessageB() . . . };

Получается, чтобы добавить новое сообщение надо врукопашную редактировать таблицу сообщений, что не совсем удобно. Как бы извернуться, чтобы эта таблица наполнялась сама на этапе компиляции?

[GBee]

2Psycho Tiger, поэкспериментирую на досуге. Спасибо за инфу.

2zhoran, Котяра вам как раз предлагал вариант этот.

[dimarik]

Я вижу два пути.
Первый путь сильно завязан на протоколе передачи данных. Все ключевые зависимые классы реализуют интерфейс IExternalizable. Через этот интерфейс происходит десериализация потока от служб доставки данных, а при необходимости и сериализация объектов с последующей передачей службам (никогда не пользовался сериализацией для отправки на сервер).

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

[Psycho Tiger]

@dimarik, понятно, спасибо.
2 путь имеется ввиду что-то вроде:

_serverConnector.deserializator = new SomeServerDeserializator();
...
var response:ServerResponse = _serverConnector.readResponse();
new _someDomain.getDefinition(response.commandName)(response.commandData);

Добавлено через 2 минуты

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

Получается, чтобы добавить новое сообщение надо врукопашную редактировать таблицу сообщений, что не совсем удобно. Как бы извернуться, чтобы эта таблица наполнялась сама на этапе компиляции?

На самом деле можно пользоваться getDefinition или getDefinitionByName, но тогда придется создавать каждый раз экземпляр класса при ответе от сервера (я не вижу ничего плохого). Однако, проблема будет теперь состоять в том, чтобы вкомпилить эти классы в swf, например, упомянув их в коде явно.

[wvxvw]

Switch сам по себе не плохой, но почему-то всегда, когда я с ним сталкиваюсь, он не там, где нужно... И это потому, что switch имеет тенденцию повторятся (т.е. если вы видите, что вы делаете свитч по значениям того же энумератора дважды и более раз, или просто по тем же значениям - you are doing it wrong!). Т.е. вы скопипастили какую-то логику, и вы за это поплатитесь, потому, что природа не терпит повторений, и стремится все ее части сделать уникальными Если в switch'е, в каком-нибудь кейсе есть более одной строчки, через месяц там будет красоваться if, а через два логика програмы будет на столько испохаблена, что разобраться почему там теперь вложенный switch уже не реально. Switch располагает к созданию фиктивных конструкций, часто нужных только для того, чтобы switch работал, что, естественно загромождает и замусоривает код. В большинстве случаев кейсы можно вынести во внешние файлы настроек или заменить нормальными методами. Кроме того, иногда switch используется для хранения состояния приложения - за это природа не просто наказывает... за ней еще и суд присяжных может следом добавить... Т.е. для создания супер-надежных программ switch очень плохой помощник. Если вы использовали его вместо того, чтобы создать state и описать в нем, что делает программа при определенных обсоятельствах - не дай бог вам программировать ПО для хирургии... потом к компутеру будет страшно подойти (непридуманная история).