Флэш Потрошитель

25.Апрель.2008

Prana Framework меняет разработку Flex и AS3 приложений

Обращение контроля, оно же IoC, оно же Inversion of Control, он же Термин с Непростой Судьбой (в Википедии статью 'Обращение контроля' даже удалить собираются) — это архитектурный принцип в разработке приложений, целью применения которого является снижение связанности приложения, в частности, за счет обращения связей в противоположную сторону (почитайте о "принципе Голливуда" или о еще одной попытке фомализовать этот подход). И флэшеры уже об этом писали. Науке также известно, что Обращение Контроля связано с Внедрениием Зависимости (которое описано намного детельнее, что все равно не спасает его от возможного удаления из Википедии. ЖЕСТЬ).

Prana Framework решает эту и другие проблемы

Этот фреймворк позволяет вам ненавязчиво конфигурировать объекты и компоненты приложения путем описания их во внешнем xml-документе и их загрузки во время выполнения. Кроме того, Prana Framework включает классы-утилиты для конфигурирования и расширения приложений на Cairngorm и PureMVC, плюс Reflection API, плюс множество утилит общего назначения. Планируется поддержка AOP (аспектного программирования) и Mock-объектов для FlexUnit.

Почитать доку к Prana Framework, скачать Prana Framework, войти в Prana Framework.

16.Июнь.2006

Слипшиеся классы и как их разлепить

Update: Чем дальше я читал статью Фаулера об инверсии зависимостей (dependency injection), тем яснее видел, сколь наивна моя нижеприведенная попытка эту инверсию реализовать. Однако оставляю все как было напечатано. Кстати, на эту же тему есть отличная статья на русском: "Инверсия зависимостей при проектировании Объектно-Ориентированных систем". Долой костыли!

Возвращаясь к начатому Клишиным разговору о впрыскивании зависимостей в классы. Если коротко -- чтобы использующие друг друга классы меньше друг от друга зависели, то есть чтобы их действительно можно было безболезненно переносить из проекта в проект, придуман механизм наружного "вкалывания" в них этих зависимостей. Сначал постмотрим, как без этого; так, если написать в своем классе:

static private var app: App = App.getInstance();

static private var dc:Function = DelegateExt.create;

static private var debug:Function = Debugger.getInstance().debug;

то даже в таком простом случае получим залипший именно на данной конфигурации класс, предполагающий, что для делегирования в нем всегда будет использоваться метод "DelegateExt.create", для трассировки -- Debugger.getInstance().debug, а класс основного приложения всегда называется App. Для внедрения такого класса в другую структуру придется преписывать его код, а это нехорошо.

Чтобы решить эту проблему и снизить зависимость классов друг от друга, и придуман механизм "Dependency Injection", т.е. -- "вкалывание зависимостей". Суть его в том, что зависимые от внешних изменяющихся классов пременные приобретают свои зависимые значения не внутри самого класса при объявлении, а задаются снаружи -- так мы уходим от необходимости переписывать класс при его переносе в другие проекты. Для впрыскивания зависмостей существует несколько методов, описанных по приведенной выше ссылке. Среди них -- метод сеттеров, когда зависимые свойства задаются через функции-сеттеры -- мне он понравился воей простотой.

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

Сам класс Ummmmm, использукющий вколотые зависимости:

class Ummmmm extends UIObject {

	/*

	 * Dependency Injection Declarations

	 */

	private var app		: Object;

	private var debug 	: Function;

	private var dc 		: Function;

	private var transformee : MovieClip;

	

	/*

	 * Dependency Setter

	 */

	public function setDependencies(obj : Object) {

		for (var i:String in obj){

			this[i] = obj[i];

		}

	}

Пример использования:

ummmmm = Ummmmm.getInstance();

ummmmm.setDependencies({app:getInstance(), dc: DelegateExt.create, debug: Debugger.getInstance().debug});

Работает. Но должны быть в такой простоте и подводные камни.. предлагаю обсудить!