Краткий смысл паттерна в том, что мы ожидаем присваивание значений набору свойств компонента в течение одного кадра 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.

Известный товарищ 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 для которого запрашивалось серверное значение. То-есть, мы, отказываясь от контекста функции вообще, используем экземпляр вспомагательного класса, для сохранения нужных значений.

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

class ServiceBase
{
	public function ServiceBase(destination : String,
		resultHandler : Function = null, faultHandler : Function = null)
	{
		_resultHandler = resultHandler;
		_faultHandler = faultHandler;

		_remoteObject = new RemoteObject(destination);
	}

	protected function call(name : String, args : Array) : void
	{
		CursorManager.setBusyCursor();

		var operation : AbstractOperation = _remoteObject.getOperation(name);
		operation.addEventListener(ResultEvent.RESULT, onResult);
		operation.addEventListener(FaultEvent.FAULT, onFault);
		operation.send.apply(operation, args);
	}

	protected function onResult(event : ResultEvent) : void
	{
		CursorManager.removeBusyCursor();

		if (_resultHandler != null)
		{
			_resultHandler(event.result);
		}
	}

	protected function onFault(event : FaultEvent) : void
	{
		CursorManager.removeBusyCursor();

		if (_faultHandler != null)
		{
			_faultHandler(event.fault);
		}
	}

	private var _resultHandler : Function;

	private var _faultHandler : Function;

	private var _remoteObject : RemoteObject;
}

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

class GuestbookService extends ServiceBase
{
	public function GuestbookService(resultHandler : Function = null,
		faultHandler : Function = null)
	{
		super("GuestbookAction", resultHandler, faultHandler);
	}

	public function getGuestbookEntries() : void
	{
		call("getGuestbookEntries", arguments);
	}

	public function getEntryById(id : Number) : void
	{
		call("getEntryById", arguments);
	}

	public function updateEntry(id : Number, text : String) : void
	{
		call("updateEntry", arguments);
	}
}

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

new GuestbookService().updateEntry(5, "Nice solution!");

или

new GuestbookService(onGetEntryById).getEntryById(6);

function onGetEntryById(result : GuestbookEntry) : void
{
	_list.addItem(result);
}

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

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

Так же, подобное решение может вам помочь при юнит-тестировании, подменяя базовый класс чем-то вроде MockServiceBase.