Update. Дописанный примерчик по теме.
Каждый флэш разработчик сталкивается в своей жизни с понятием СОСТОЯНИЯ объекта. Часто до какого-то момента человек не осознает, что он снова и снова придумывает себе то, чем наука уже давно пользуется — конечный автомат. Порой, это не так очевидно. Но, мне уже долгое время такой подход к проектированию помогает не тратить время на непонятные баги.
Представим простой пример. Есть флэшовое меню. Кто из нас не делал флэшовых меню, правда? У него (в зависимости от сложности), есть состояния, например: закрыто, анимация, открыто. Вы не представляете СКОЛЬКО я видел (да что тут преукрашать, и сам делал) менюшек, которые глючили из-за того, что что-то происходило в ненужном состоянии. Если их всего три, то, скажем реакцию на нажатия во время анимации можно легко отключить, чтобы ничего не ломалось. А что если у меня ветвящаяся цепочка изменения множества визуальных элементов, которая может быть прервана и выполнена в обратном направлении в наборе ключевых точек? Вот тут начинается жопа с отладкой, если в самом начале не принять мер.
Я помню свой пример десятикратно вложенных IF-ов с кучей переменных и граничных условий. Все это легко заменялось набором состояний с переходами.
Давно уже я себе слепил простую библиотечку для работы с состояниями, переходами и событиями. Неделю назад я на нее посмотрел трезвым взглядом и выкинул 90% всяких ненужных вещей и левого функционала. Осталась простенькая штуковинка, которая уже неделю успешно применяется вместо старого монстра. Фиксятся косячки, но тем не менее.
Идея — простая переформулировка вышесказанного. Есть состояния, возможные переходы между состояниями (в том числе и сложные) и события. Соответственно, чтобы указать, что мне нужно это событие в этом состоянии, я навешиваю на него листенер. Также навешиваются листенеры на сами переходы из состояния A в состояние B.
Пока писал, придумал BUG. При составном переходе из A в B через C будет евент перехода из A в C и из C в B, а не ожидаемый A в B. Записал пофиксить на выходных.
Как дотестирую еще, выложу на какой-нить гуглокод. Пока, выдержка из readme.
/**
* РУКОВОДСТВО.
* 0. Все состояния имеют строковые имена. Допустим, что
* const INVISIBLE, VISIBLE, SHOW содержат названия состояний.
* 1. Добавить состояния
* // Просто добавляет состояние без перехода
* state.add( INVISIBLE );
* // Добавляет состояние INVISIBLE и переход из него в VISIBLE
* state.add( INVISIBLE, VISIBLE );
* // Добавляет состояние INVISIBLE и переход из него в VISIBLE через SHOW
* state.add( INVISIBLE, VISIBLE, SHOW );
* Когда добавляется самое первое состояние, оно принимается за текущее. При этом не срабатывают события смены состояния.
* Второй параметр функции может быть массивом состояний.
* 2. Определить листенеры смены состояний
* // Выполняет stateVisible, когда состояние из любого меняется на VISIBLE
* state.addTransitionListener( StateMachine.ANY, VISIBLE, stateVisible );
* // Выполняет stateShow, когда состояние меняется с INVISIBLE на SHOW
* state.addTransitionListener( INVISIBLE, SHOW, stateShow );
* 3. Определить листенеры событий
* // Вызывает doShow, когда событие “show” диспатчится в любом состоянии
* state.addEventListener( StateMachine.ANY, “show”, doShow );
* // Вызывает doHide, когда событие “hide” диспатчится в состоянии VISIBLE
* state.addEventListener( VISIBLE, “hide”, doHide );
* Листенеры событий являются просто колбэк функциями, и не имеют отношение к флэшвой событийной системе и классу Event
* 4. Поустанавливать состояния и посмотреть работают ли листенеры изменений
* state.setState( VISIBLE );
* 5. Подиспатчить события и посмотреть работают ли листенеры события
* state.dispatch( “hide” );
*
* ПОСЛОЖНЕЕ.
* 0. Если состояние из текущего в требуемое не может быть изменени, то оно просто не изменяется. Никаких ошибок не выбрасывается.
* 1. Если нужно добавть двусторонние транзишены, например из состояния A в B и из B в A, используйте метод addTwoWay().
* addTwoWay( A, B, via: * = null);
* 2. Чтобы передать параметры листенерам событий, используйте второй параметр.
* Можно передать как один аргумент так и массив аргументов.
* dispatch( name, args: * = null )
* 3. Можно удалить листенер перехода или события.
* removeTransitionListener() and removeEventListener();
* 4. Цепочки состояний.
* Можно создавать сложные переходы через виртуальные и реальные состояния. Виртуальное состояние — это состояние,
* которое не было зарегистрировано методом add() и не имеет переходов из/в себя. Чтобы использовать цепочки,
* нужно указать промежуточные состояния в третьем параметры метода state.add(). Это может быть единичное состояние
* или массив состояний.
* state.add( INVISIBLE, VISIBLE, SHOW ) создаст такой переход:
* INVISIBLE –> SHOW –> VISIBLE. При переходе на внутренний состояния также срабатывают все листенеры. Здесь
* SHOW — виртуальное состояние. Эта конструкция считается одним переходом из INVISIBLE в VISIBLE, но как видите
* является асинхронным переходом. Состояние SHOW может выполняться какое-то время что-то рисуя на экране,
* когда оно заканчивается, нужно вызвать метод state.release(), иначе конечный автомат никогда не выйдет из
* этого состояния.
* Выполнение цепочки может быть остановлено только в реальных состояниях и если canChangeStateDuringTransition == true.
* Это случается, если смена состояния запрашивается во время перехода. Новое состояние встает в очередь и рассматривается
* после завершения перехода.
*/
И временная ссылочка.
