XML ленты| « flex-coding-guidelines | Публичные переменные...это зло » |
Пример неудачного, использования CairngormEventDispatcher
Краткое описание действующих лиц.
Паттерны программирования
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
http://zeus.sai.msu.ru:7000/SE/project/pattern/index.shtml
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/singleton.htm
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/
J2EE (Java 2 Enterprise Eddition)
http://ru.sun.com/java/j2ee/index.html
http://www.codenet.ru/webmast/java/j2ee.php
J2EE Patterns
http://java.sun.com/blueprints/patterns/catalog.html
http://www.patterndepot.com/put/8/JavaPatterns.htm
Cairngorm Микро архитектурный фреймворк, основанный на J2EE паттернах, адаптированных для flex /flash (ria). Т.е. это реализация нескольких паттернов для flex и общая рекомендация о связке между ними.
CairngormEventDispatcher – Централизованный диспетчер событий, Singleton.
Позволяет послать событие из любой точки программы.
CairngormEvent – пользовательское событие, его можно переопределить для отсылки данных вместе с событием.
MyEvents.MY_EVENT – имя пользовательского события, которое ассоциируется с командой.
отсылаем событие:
- var theMyEvent : CairngormEvent = new CairngormEvent( MyEvents.MY_EVENT );
- CairngormEventDispatcher.getInstance().dispatchEvent ( theMyEvent );
Архитектура Cairngorm подразумевает, что обработка этих событий будет реализована через FrontController, который определяет соответствие событий и команд(ICommand). Другими словами, обработка реакции на события происходит централизованно.
Но существует возможность подписаться на это событие в любом месте приложения. Без использования команд и FrontController.
подписываемся на событие без использования комманд:
- CairngormEventDispatcher.getInstance().addEventListener ( MyEvents.MY_EVENT, MySuperHandler );
На первый взгляд данная возможность впечатляет: кто угодно может обратиться к кому угодно из любой точки приложения.
Но если Вы напишите достаточно много таких вызовов, то потеряете контроль над своим приложением. Особенно, если работаете в команде над общим кодом.
Первая проблема, которую я вижу, это циклический вызов. Остальные предоставлю вам найти самостоятельно, если всё же решите использовать данную конструкцию.
Bookmark this article at
4 комментариев
Или я чего то не догоняю?
Для простых взаимодействий достаточно стандартных событий.
Общий принцип применения команд - использовать их для действий, меняющих модель.
Тогда возможно реализовать функциональность undo, redo. Это, конечно, не панацея, возможны исключения.
В использовании нескольких Model нет ничего страшного, если данные
разделяются. Их можно ещё разбить по функциональности. Например, информация о состояниях может отделяться
от обычных данных.
Инкапсуляция это скрытие реализации. Так и получается, что команда инкапсулирует реакцию на событие.
Ты можешь менять объекты, которые выполняют команду, но это уже внутренняя низкоуровневая реализация.