Еще один вопрос по архитектуре

[Vier]

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

Я подозреваю, что есть способ как-то аккуратнее все это организовать. Интересно было бы узнать.

[random13]

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

[incvizitor]

Vier, вот и я, когда только начинал немного разбираться в AS3, хотел составить нейкие шаблоны для загрузки xml + картинки и т.д. Но, поверьте мне, всё уже проще простого, вот увидите через 2 месяца будете на автомате писать эти 2-3 метода за 2 минуты))

Добавлено через 1 минуту
Киньте может код для примера? Подскажем что где заоптимизировать или упростить (если есть что ).

[Division]

Я решал такое создав набор классов, реализующий очередь действий.
Есть класс, реализующий загрузку XML и класс, загружающий картинки.

Actions.instance.addAction(new GetXmlAction(XML_URL));
Actions.instance.addAction(new LoadImagesAction(), true);
Actions.instance.start();

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

Не сказал бы что при таком решении становится намного проще (:

[random13]

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

Я решал такое создав набор классов, реализующий очередь действий.
Есть класс, реализующий загрузку XML и класс, загружающий картинки.

Actions.instance.addAction(new GetXmlAction(XML_URL));
Actions.instance.addAction(new LoadImagesAction(), true);

Таким образом LoadImagesAction может принимать в качестве параметров загруженный XML.

Не сказал бы что при таком решении становится намного проще (:

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

хотя это плодит в данном случае новые сущности

[Division]

Не совсем рефакторинг, скорее подход такой к созданию логики приложений (: Не всегда оправдано, но местами удобно.

[Vier]

Спасибо всем, да придется тогда лучше структурировать самому )

Пример кода вечером скину. Я уверен, что где-то я неправильно пишу.

[Life_Master]

Division, хм... интересно, а по-подробнее о таких классах можно...

[inozemcev]

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

[expl]

Actions.instance.addAction(new GetXmlAction(XML_URL));

Надо же, у нас тоже асинхронные команды Action-нами называются
Только синглтон здесь нафиг не нужен - делаем асинхрнонную команду MacroAction,
принимающую список асинхрнонных команд - и запускаем ее, можно делать вложенные списки комманд

Там где логика ветвится - например в одном случае надо запускать одну цепочку - в другом другую - в акшене просто запускаем либо однин MacroAction, либо другой

Где цепочка строго определена (у нас только в лоадере основной swf-ки используется) - можно подобием конвеера Потапенко воспользоваться, в других случаях он слишком НЕгибок.

Но интуиция подсказывает, что обилие цепочек свидетельствует о хреново продуманной архитектуре - надо разруливать как-то по другому.
(комманда - это всетки не эквивалент реального объекта)