В Silverlight все отлично, начиная от возможности писать код на всех языках из семьи .NET (ну, конечно же, самый популярный это красавец С#), заканчивая продуманной иерархией визуальных компонентов и возможности их полного видоизменения. Двусторонний биндинг, LINQ, нормальная поддержка ООП, Expression Blend как средство, прошу заметить, удобного «design mode» и т.п.

Есть и некоторые проблемные места, которые во Flex работают из коробки, например невозможность использовать свои курсоры, отсутствие чего-то на подобии PopUpManager, и нативного drag-n-drop. Но это все делается довольно быстро вручную.

В общем, я бы уже и смирился бы с мыслью, что Flex удел мучеников и желающих и далее подставлять костыли в индуский вонючий код, как был просто повержен беглым анализом новых фичей беты Flex 4!

Это был катарсис, оказывается в Adobe не все заснули в двухлетнюю спячку, оказывается они поняли, что раз Microsoft, возможно и своровали идею MXML, binding и вообще флекса как технологии (отмывши это все от толстого слоя ила из берегов Ганга), им ничего не мешает сделать то же самое. И вот, пожалуйста, новый фреймворк визуальных компонентов Spark, который один к одному копирует подход Template Design-а в архитектуре контролов Silverlight, это подробнее обсудим в следующих статьях. Вот тебе и пока-что хромающий Flash Catalyst, идеологическое подобие Expression Blend, вот тебе и новый язык векторной разметки на основе MXML — FXG!, точная копия набора примитивов из XAML (Rect, Ellipse, GradientFill и т.п.). Без которого немыслимо то самое разделение труда дизайнера и программиста.

Мало того, после просмотра исходного кода спарковских контролов, у меня возникло впечатление, что его писали уже люди, а не человеко-недели. Это же можно читать! Подозреваю, что Adobe всё-таки наняла нормальных архитекторов и программистов из штатов. Что конечно достойно глубокого поклона с моей стороны.

В общем, я несказанно счастлив, что теперь есть в чём разбиратся дальше. И что, возможно, вернусь в лоно флекса, как тот самый библейский блудный сын. Конечно же, как говорится, что-бы победить нужно узнать все слабости врага, чем, можно сказать, я сейчас и занимаюсь. Пожалуй в этом контексте и попробую написать несколько статей, не просто сравнивая Silverlight и Flex (слава Богу, сейчас это уже возможно), а рассматривая конкретные подходы в проектировании приложений, которые можно применять на обеих платформах. До встречи, друзья.

Содержание выступления, лично для меня, не несло новую информацию, скорее это был скомпилированый экскурс по текущим RIA технологиям: AJAX, Flex, Silverlight, JavaFX, чем практичный тренинг. Но, тем не менее, рассказ был очень интересным. Яков —  отличный докладчик. На докладе прозвучали всякие закулисные сплетни, которые обычно не публикуются в блогах или новостях. Например, почему разработчики Adobe AIR не добавляют в свой продукт расширенный доступ к ОС и т.п.

Основные полезные, на мой взгляд, тезисы:

• Silverlight уже догнал Flex в технологическом контексте, осталось только повысить колличество инсталяций плагина у пользователей;
• Яков против всех сторонних фреймворков для Flex, он считает что Flex вполне самодостаточный фреймворк и не стоит его утяжелять дополнительными абстракциями. Я с этим, конечно же, не согласен — это вообще странное заявление. Наводит на мысль о том, что в основном Farata  Systems разрабатывает проекты ориентированые на визуальное представление, а не на сложную бизнес-функциональность;
• Если вы сталкиваетесь с ошибками Flex фреймворка (а это неизбежно), вы должны наследовать и исправлять, если не получается наследовать — copy-paste. Яков мотивирует это тем, что в каждой новой версии Flex всё равно перепишут до неузнаваемости, по-этому не стоит тратить время на «изящные фиксы»;
• Не нужно ждать исправления «знаменитых багов». Чинить нужно самому. Яков, пояснил, что большие компании имеют собственное видение своих продуктов, которое не всегда пересекается с интересами вашего проекта, по-этому хорошая практика предполагает ориентацию на починку своих проблем собственноручно.

Вообще, Яков довольно прагматичный человек, все суждения которого воспринимаются хоть и неожидано, но без особых внутренних возражений. Возможно это из-за того, что я не менее прагматичен чем он?.. В заключении своего выступления, он рассказал о двух самых главных проблемах программистов из СНГ:

• Плохое знание английского языка;
• Завышеное самомнение, которое сопряжено с конкретными проблемами в разработке. Яков утверждает, что при работе с нашими ребятами он не раз напарывался на неприятный факт уверенности их в том, что они лучше знают что нужно заказчику, чем сам заказчик.

И, что-бы поддержать свой внутренний прагматичный уровень, я не могу не согласиться с данными заявлениями, так как сам являюсь живым примером подобных тенденций — нужно работать над собой.

Доклад удался. Слава Богу, что Microsoft искупает свои грехи подобными бесплатными мероприятиями, а так же бесплатным печеньем и кофе.

Краткий смысл паттерна в том, что мы ожидаем присваивание значений набору свойств компонента в течение одного кадра Flash Player-а, а последующюю логику обработки этих значений переносим на следующий кадр. Это может повысить производительность приложения, а так же навести порядок в обработке значений связанных между собой свойств компонента.

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

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

Я подготовил простой пример, который демонстрирует суть задачи.

Допустим у нас есть класс модели OpportunityDTO, экземпляры которого получаются от сервера и создаются AMF десериализатором Flash Player-а, который нам не подконтролен. В нём есть два свойства date, children, в момент присваивания значений которых, нам нужна дополнительная обработка. Эта обработка должна выполняться только тогда, когда оба свойства получили свои значения. Типичный случай для паттерна инвалидации свойств.

package com.tearaway_tea.model
{
	import flash.events.EventDispatcher;

	import mx.collections.ArrayCollection;

	import org.goverla.interfaces.IPropertiesInvalidable;
	import org.goverla.managers.PropertiesInvalidationManager;

	public class OpportunityDTO extends EventDispatcher implements IPropertiesInvalidable
	{
		public function get date() : Date
		{
			return _date;
		}

		public function set date(value : Date) : void
		{
			_date = value;
			_dateChanged = true;
			invalidateProperties();
		}

		public function get children() : ArrayCollection
		{
			return _children;
		}

		public function set children(value : ArrayCollection) : void
		{
			_children = value;
			_childrenChanged = true;
			invalidateProperties();
		}

		public function invalidateProperties() : void
		{
			PropertiesInvalidationManager.instance.invalidateProperties(this);
		}

		public function commitProperties() : void
		{
			if (_dateChanged && _childrenChanged)
			{
				_dateChanged = false;
				_childrenChanged = false;

				for each (var item : ItemDTO in children)
				{
					item.name += "/" + date.toString();
				}
			}
		}

		private var _date : Date;

		private var _dateChanged : Boolean;

		private var _children : ArrayCollection;

		private var _childrenChanged : Boolean;
	}
}

Для решения этой задачи я предлагаю использовать синглтон PropertiesInvalidationManager, который работает по образу и подобию флексовского LayoutManager-а.

package org.goverla.managers
{
	import mx.rpc.AsyncDispatcher;

	import org.goverla.interfaces.IPropertiesInvalidable;

	public class PropertiesInvalidationManager
	{
		public static function get instance() : PropertiesInvalidationManager
		{
			if (_instance == null)
			{
				_instance = new PropertiesInvalidationManager();
			}
			return _instance;
		}

		private static var _instance : PropertiesInvalidationManager;

		public function invalidateProperties(target : IPropertiesInvalidable) : void
		{
			if (_targets.indexOf(target) < 0)
			{
				_targets.push(target);

				if (_dispatcher == null)
				{
					_dispatcher =
						new AsyncDispatcher(commitProperties, [], 0);
				}
			}
		}

		public function commitProperties() : void
		{
			for each (var target : IPropertiesInvalidable in _targets)
			{
				target.commitProperties();
			}
			_targets = [];
			_dispatcher = null;
		}

		private var _targets : Array = [];

		private var _dispatcher : AsyncDispatcher;

	}
}

Суть очевидна. Менеджер получает ссылку на объект, который нуждается в инвалидации свойств, ставит его в очередь и на следующем кадре вызывает у него commitProperties(). Для откладывания выполнения используется флексовский AsyncDispatcher, который основан на Timer.

Для удобства использования, можна создать какой-то базовый класс, который будет имплементировать интерфейс IPropertiesInvalidable.

Но, несмотря на немногочисленную аудиторию, я с удовольствием посмотрел и послушал выступление создателя библиотеки Away3D, Александра Задорожного, как часть доклада «Трёхмерные вебсайты и вебсервисы: возможности, преимущества и перспективы». Он, довольно грустно поведал о разочаровании последней версией Flash Player 10 на предмет отсутствия ожидаемой полной поддержки 3D, а не только базового функционала. Сказал, что забросил своё детище, хотя и удивлён тем, что, проект Away3D так долго существует (связывает это с низкой функциональностю API Flash Player-а).

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

По уже сложившейся «традиции», после моего выступления Сергей Байдачный из Microsoft рассказал о Silverlight. На этот раз о новых фичах третьей беты. Вообще, мне очень интересна тема разработки на Silverlight (думаю, как и большинству сознательных флексеров). Flex до сих пор сложно назвать самым крутым средством для RIA, ввиду забивания со стороны Adobe на большинство вопросов программистского характера (рефакторинг, логичной и управляемой снаружи ООП моделью базовых компонентов, возможности языка Action Script). Так как Silverlight является наследником крутейших средств и методологий .NET-а, то он априори — крут, крут, крут.

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

Программа потока Интернет-технологии — http://iforum.com.ua/programma-tech/.

P.S. Кстати нашёлся животрепещущий экземпляр сомнительного применения технологий Flash и Flex, ввиде движка Fuzlle CMS (слоган — «Подвигай!»). После оригинальной статьи на Хабре с призывом покупать лицензии и всё такое, я заинтересовался, что же это за феноменальная разбработка. Представте, админка, написанная на Flex, в которой можно создавать динамические сайты-визитки на флеше, интегрируя дизайн за 5 минут используя при этом привлекательную анимацию. Заманчиво, не так ли?

А вот и результат (http://sekistov.ru/app/):

Пожалуй, это даже грандиознее чем top4top.

Некоторые коллеги постоянно норовят разузнать все детали и нюансы использования Mate на практике и в связи с этим я решил описать пример типового архитектурного решения основанного на модели реального приложения. Он похож на примеры с сайта фреймворка, но расписан пошагово с конкретными рекомендациями на всех уровнях.

Итак, я подготовил проект opportunities (так сказать, подающий большие надежды) на Google Code с доступными исходниками. Для начала рассмотрим его он-лайн:

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

Я использую, так называемую схему «двустороннего коммуницирования посредством модели и инжектинга», на сайте фреймворка есть отличная диаграма как этого так и других приёмов:

Рассмотрим каждый элемент диаграмы основываясь на классах моего примера. Пункт 3 исключаем, так как для доступа к серверу мы используем специальный класс сервиса OpportunitiesMockService наследуемый от ServiceBase (я уже описывал этот приём ранее).

Model

Я определил три класса модели. Самый элементарный, зависимый от представления, класс элемента списка OpportunityVO. Второй класс OpportunitiesDataProvider, является списком экземпляров OpportunityVO, он инкапсулирует в себе вызовы серверных методов и для удобства наследуется от ArrayCollection. Это даёт возможность использовать его провайдером данных для большинства списочных компонентов из Flex фреймворка.

Третий — OpportunityDataProvider, предназначен для работы с конкретным редактируемым OpportunityVO из списка. У него есть публичное свойство opportunity, а также методы для манипуляций с ним. Этот класс диспатчит события opportunityCreated и opportunitySaved типа DataProviderEvent, которые информируют о завершении обработки opportunity (так как эти действия зачастую связаны с вызовом серверных методов, мы неможем ожидать их синхронного выполнения в потоке вызова методов класса). Реализация класса очень простая, но в реальности, в него нужно помещать все трансформации, инициализации и прочие процедуры над элементом, которые не связаны с логикой работы представления, и вполне успешно могут быть отделены от него.

Так же есть вспомогательный класс OpportunityViewState, который используется для хранения информации о текущей видимой форме в представлении. Подобные классы приходится создавать для решения коммуникационных нюансов Mate, далее я их детально опишу.

View

Для представления также определены три класса, первый OpportunitiesListView для показа списка элементов. У него есть одно публичное свойство dataProvider, а также, он диспатчит два события createOpportunity и editOpportunity типа OpportunityEvent, которые говорят сами за себя.

Второй класс OpportunityEditView определяется свойством opportunity, в которое нужно присваивать непосредственно объект редактирования OpportunityVO, а также он диспатчит другие два события saveOpportunity и closeOpportunity также типа OpportunityEvent.

Третий — Index, является композицией предыдущих. В нём доступно свойство selectedIndex, которое определяет текущую видимую форму.

Это наше представление. Как видим, его классы наследуются от стандартных контейнеров Flex фрейворка, они не имеют зависимостей от провайдеров данных модели, являются пассивными и выглядят как довольно самодостаточные компоненты для повторного использования — то, что нам и нужно.

Mate Event Maps

Перейдём непосредственно к роли Mate в связывании модели и представления. Все декларации этого фреймворка описываются в так называемых «картах событий». Это MXML файлы, которые поддерживают биндинг и все остальные удобства Flex Builder-а. По мере увеличения проекта, эти карты довольно сильно разростаются, так что для разных групп коммуникаций я завожу отдельные файлы. В данном примере их четыре.

Одна из карт — DataInjectionMap, описывает связи между представлением и моделью, выполняется только один раз при запуске приложения. Это частичная реализация паттерна IoC (Inversion of Control), которая работает необычным образом: при необходимости, она создаёт только экземпляры классов модели и слушая события родительского Application, в момент создания представлений, выполняет описанные связывания. Типичная нотация с использованием тегов Injectors и PropertyInjector:

<Injectors
	target="{OpportunitiesListView}">
 	<PropertyInjector
		targetKey="dataProvider"
		source="{OpportunitiesDataProvider}" />
</Injectors>

Здесь мы задаем связь на основе биндинга между экземплярами классов OpportunitiesListView и OpportunitiesDataProvider посредством свойства dataProvider, данные которого в результате попадут в DataGrid.

Остальные: OpportunitiesEventMap, DataProviderEventMap, NavigationEventMap, непосредственно описывают действия, которые должны происходить при попадении в поле видимости Mate (Event Bus) каких-либо событий как из представления так и из классов модели. Например, нотация с использованием тегов EventHandlers, MethodInvoker и EventAnnouncer:

 <EventHandlers
	type="{OpportunityEvent.EDIT_OPPORTUNITY}">
 	<MethodInvoker
		generator="{OpportunityDataProvider}"
		method="editOpportunity"
		arguments="{[event.data]}"/>
 	<EventAnnouncer
		type="{NavigationEvent.NAVIGATE_EDIT_VIEW}"
		generator="{NavigationEvent}"/>
</EventHandlers>

Это выражение читается так: в тот момент когда представление продиспатчит событие editOpportunity (по-сути нажатие кнопки Edit), у экземпляра класса модели OpportunityDataProvider должна запуститься операция редактирования экземпляра класса OpportunityVO, которые доступен из события.

Так же, посылается специальное событие NavigationEvent, в результате которого представление должно переключиться в режим редактирования. Внутри класса OpportunityDataProvider, должен произойти вызов серверного метода для получение экземпляра OpportunityVO с последним состоянием элемента (но в моём примере, я упростил схему, и сохраняю в свойстве opportunity модели, тот же объект). Далее, так как мы указали связывание (injection) в DataInjectionMap между OpportunityEditView и OpportunityDataProvider по свойству opportunity, редактируемый элемент будет доступен в представлении.

В свойствах generator или source вышеописанных тегов, мы указываем класс модели, не экземпляр этого класса. Mate автоматически создаст экземпляр в нужный момент, причём, по-умолчанию, только один раз. Фреймворк имеет внутренний кеш для всевозможных экземпляров модели или событий, и ищет там необходимые объекты для повторного использования. Эта схема похожа на паттерн Singleton, но она гораздо практичнее, так как нет лишнего связывания между сущностями системы, которые неизбежны при использовании «одиночек» (кстати, довольно сильный недостаток прочих фреймворков типа Cairngorm или PureMVC).

И напоследок, рассмотрим специфику карты NavigationEventMap, в которой описаны ответные действия на события NavigationEvent. В общем-то, переключение режимов представления могло бы быть реализовано непосредственно в нём. Но, как показала практика, в больших проектах, визуально легче контролировать подход внешнего управления представлением. Например, если необходимо подключить deep-linking (поддержку изменения адресной строки броузера), мы введём ещё один тип событий BrowserNavigationEvent, которые будут использовать уже готовые списки действий в картах Mate. Итак, нотация:

<EventHandlers
	type="{NavigationEvent.NAVIGATE_EDIT_VIEW}">
 	<MethodInvoker
		generator="{OpportunityViewState}"
		method="setSelectedIndex"
		arguments="{[1]}" />
</EventHandlers>

При попадении в Mate события navigateEditView, вызывается метод у вспомогательного класса модели OpportunityViewState, который является проксирующим. Я не хотел бы вводить для этих целей этот класс, а бы присваивал значения в selectedIndex прямо в классе представления Index, но в свойство generator тега MethodInvoker (как и всех других тегов), нельзя указывать классы визуальных компонентов (то-есть можно, но это будет неправильно, так как фреймворк создаст экземпляр, недоступный никому). Суть в том, что, как я уже писал выше, Mate не создаёт экземпляры визуальных компонентов(и не пытается, это делает MXML), он слушает события всего приложения, и когда компонент попадёт в display list флеш плеера, фреймворк начинает с ним «сотрудничать» (зачастую для определения (injection) зависимостей). Получается, что есть внутренний кеш всех созданных классов самим фреймворком и отдельный список компонентов, которыми заведует сам флеш плеер и они не пересекаются между собой.

Вот и всё. Информацию о всех доступных тегах фреймворка можна найти в документации на сайте Mate. Надеюсь описание не получилось чересчур запутанным. С удовольствием отвечу на все адекватные вопросы по теме.

P.S. Кстати, на днях вышло обновление Mate до версии 0.8.7, в котором появилась возможность задавать связи (injection) между интерфейсами.

Нам нужен ещё один человек. Желательно начинающий, можно студент, очень энергичный и с толковой головой(акцентировка на ООП). Не нужен флексер-профи(их мало, в основном все врут), приветствуются специалисты из C#, Java.

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

Кто заинтересован, оставляйте адреса в комментах.

UPD. Работа предполагает полную занятость в офисе, в городе Киеве, Украина.

UPD. Вакансия закрыта — новый сотрудник найден.

В последнее время писать мне хочется всё больше и больше — верный показатель старения и остепенения.  Да и писать есть о чём, хоть Adobe до сих пор так и не выпустила Flex 4(после чего ожидается просто шквал впечатлений в блогах всех флексеров), всё таки каждый день приходится сталкиваться уже не столько с неприятностями флекса, сколько с архитектурными вызовами на смекалку.

Stay tuned.

Известный товарищ gskinner ещё в далёком 2006 году удивлялся почему все слушатели по умолчанию не подключаются в режиме weak reference, а некоторые ребята на Хабре, в комментах к статье про контексты функций, вообще считают, что «слабые» ссылки от нечистого и все операции по удалению онных нужно производить исключительно вручную!

Вместо пересказывания справочной информации я приведу пример, в котором я вижу исключительную полезность использования «слабых» ссылок.

public class GuestbookEntry
{
	public function get comments() : ArrayCollection
	{
		return _comments;
	}

	public function set comments(value : ArrayCollection) : void
	{
		if (_comments != null)
		{
			_comments.removeEventListener(CollectionEvent.COLLECTION_CHANGE,
				onCommentsChange);
		}

		_comments = value;

		if (value != null)
		{
			value.addEventListener(CollectionEvent.COLLECTION_CHANGE,
				onCommentsChange, false, 0, true);
		}
	}

	protected function onCommentsChange(event : CollectionEvent) : void
	{
		switch (event.kind)
		{
			case CollectionEventKind.ADD :
				CommentEntry(event.items[0]).guestbookEntry = this;
				break;
		}
	}

	private var _comments : ArrayCollection;
}

Представим, у нас есть гостевая книга, и тип её записи GuestbookEntry представленый выше. У этого типа есть коллекция комментариев. Пусть комментарий описывается типом CommentEntry. Где-то есть форма для добавления новых комментов, у нас есть требование архитектуры проекта, что-бы каждый коммент имел ссылку на запись книги посредством свойства guestbookEntry.

Экземпляры GuestbookEntry скорее всего будут получены от сервера, неважно. В сетере свойства comments я подписываюсь на событие изменения коллекции, что-бы контроллировать  момент добавления нового коммента. Как видим, ссылка на функцию onCommentsChange передаётся в коллекцию как «слабая» (последний аргумент метода addEventListener).

Во время профайлинга приложения с подобным кодом, до использования в нём «слабой» ссылки,  в памяти оставались все когда-либо созданые экземпляры класса GuestbookEntry. Инспектор «висячих» (англ. loitering) объектов показывал две связи между экземплярами GuestbookEntry и CommentEntry: одна посредством свойства guestbookEntry, другая, косвенная, посредством функции onCommentsChange (её экземпляр хранился в коллекции комментов, а savedThis (по-сути, контекст функции) у функции ссылался на запись гостевой).

На сколько я понял, сборщик мусора в Flash Player автоматически очищает память от связаных между собой объектов только через прямые ссылки (циклические вчастности), если же есть косвенные (все подписки на события) связи, он — бессилен. Сдесь нам и помагают «слабые» ссылки. Никакого риска использования их нет, так как это, зачастую, последние оставшиеся ссылки между объектами, готовыми к удалению.

Внимательный читатель, который любит Фаулера, заметит и спросит о том, что нам мешает удалять в ручную такие ссылки? А я отвечу — ничего не мешает, но подобные решения будут громоздкими и некрасивыми. В данном случае, мне нужно было бы реализовать в типе GuestbookEntry, что-то вроде метода dispose():

public function dispose() : void
{
	comments = null;
}

И вызывать этот метод во всех местах потенциального «прощания» с экземплярами записей гостевой книги. Скучно, старомодно и не практично.

UPD: Поразмыслив с коллегами по работе, выяснилось пару аспектов когда «слабые» ссылки могут подложить вам свинью. Например, если у вас остался «неприкаянный» объект, на который ссылаются «слабой» ссылкой, до момента уничтожения его сборщиком мусора, он будет получать события (ведь ссылка есть) и возможно, обработка этих событий будет вами не запланирована, так как вы, уже, мысленно «распрощались» с объектом. Что-бы избежать подобных ситуаций, конечно-же, нужно удалять слушателей вручную.

В данном примере криминала нет, так как записи гостевой книги с их комментариями удаляются комплексно, то изменение коллекции комментов, после удаления прямых ссылок на экземпляры GuestbookEntry и до уничтожения их сборщиком — невозможно.

Например, теперь можно описать такую функцию:

public class TestClass
{
	var property : Number;

	function updateValue(value : Number) : void
	{
		TestClass(this).property = value;
	}
}

и передавать её куда угодно:

var func : Function = new TestClass().updateValue;
func(555);

и быть уверенным, где-бы её не вызвали в this будет экземпляр класса TestClass. Но я не об этом, есть более любопытные действия, которые можно производить над функциями в Action Script, их мы их рассмотрим.

Асинхронные вызовы

Скорее всего вы сталкивались с задачей вызова удаленного метода на сервере и обработки результата этого вызова. Допустим у нас есть класс сервиса ServerService, который принимает в конструктор ссылку на функцию, которая должна обработать ответ и мы выполняем типичную задачу обновления свойства исходного объекта:

class Example
{
	function updateItem(item : SomeObject) : void
	{
		_tempObject = item;
		new ServerService(onGetResult).getResult(item.startValue);
	}

	function onGetResult(result : Object) : void
	{
		_tempObject.endValue = result;
	}

	private var _tempObject : SomeObject;
}

Всё написано верно, но зачем так сложно? Давайте упростим подобную ерунду, «умным» кодом:

function updateItem(item : SomeObject) : void
{
	new ServerService(onGetResult).getResult(item.startValue);

	function onGetResult(result : Object) : void
	{
		item.endValue = result;
	}
}

В данном случае функция onGetResult имеет доступ ко всем переменным функции updateItem и к её аргументу item в частности. Такой прием во многих случаях может сократить объем кода и убрать негативный оттенок асинхронности. Кстати, в this функции onGetResult будет уже не экземпляр Example, а просто global.

Множественные асинхронные вызовы

Ещё интереснее ситуации когда нужно сделать несколько асинхронных запросов в цикле, а затем обработать каждый ответ соответственно, например:

function updateItems(items : ArrayCollection) : void
{
	for each (var item : SomeObject in items)
	{
		new ServerService(onGetResult).getResult(item.startValue);
	}

	function onGetResult(result : Object) : void
	{
		item.endValue = result;
	}
}

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

Зачастую можно воспользоваться так называемым Loader-ом:

function updateItems(items : ArrayCollection) : void
{
	for each (var item : SomeObject in items)
	{
		new ValueLoader(item);
	}
}

class ValueLoader
{
	public function ValueLoader(item : SomeObject)
	{
		new ServerService(onGetResult).getResult(item.startValue);

		function onGetResult(result : Object) : void
		{
			item.endValue = result;
		}
	}
}

Так как контекста функции недостаточно что-бы сохранить item для обновления его после ответа сервера, мы создаем над функцией обёртку — класс, которые способен запомнить в контексте всё что нужно. Так как конструктор класса всё та же функция, аргумент item без проблем будет доступен в функции onGetResult.

Стандартизированый объект ContextFunction

В конце концов, если вы нежелаете плодить массу всевозможных Loader-ов, можно ввести универсальный тип — паттерн для многократного использования:

class ContextFunction
{
	public function ContextFunction(targetFunction : Function, ... args)
	{
		_contextArgumnets = args;
		_targetFunction = targetFunction;
	}

	public function func(... args) : void
	{
		var targetArguments : Array = args.concat(_contextArgumnets);
		_targetFunction.apply(this, targetArguments);
	}

	private var _contextArgumnets : Array;

	private var _targetFunction : Function;
}

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

function updateItems(items : ArrayCollection) : void
{
	for each (var item : SomeObject in items)
	{
		new ServerService(new ContextFunction(onGetResult, item).func).
			getResult(item.startValue);
	}
}

function onGetResult(result : Object, item : SomeObject) : void
{
	item.endValue = result;
}

Это по-сути то же решение, что и с Loader-ом, только более универсальное. Экземпляр ContextFunction сохраняет onGetResult, которая получит ответ от сервера, а также ссылку на item для которого запрашивалось серверное значение. То-есть, мы, отказываясь от контекста функции вообще, используем экземпляр вспомагательного класса, для сохранения нужных значений.

В заключение, могу вас уверить, что все эти трюки используются мной на практике очень часто и эффективно. Это не высосанные из пальца проблемы.