Лучшая практика для разработки Flash AS3 RIA - использование событий / слушателей или разрешение детям вызывать функции у родителей?

Question

Я работаю над веб-приложением, встроенным в Flash AS3.

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

(Это аналогичный шаблон, который я использую в большинстве разрабатываемых мной приложений ...)

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

Кажется, что есть два основных способа справиться с этим:

1. Иметь диалоговые окна для отправки событий, которые главный экран прослушивает
2. Разрешить диалоговому экрану вызывать функции на главном экране при нажатии этих элементов управления (для этого необходимо, чтобы на диалоговом экране была ссылка на главный экран,и что функции на главном экране являются общедоступными)

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

Но для многих RIA, которые я разрабатываю - конкретный экран ТАК ОСОБЕННЫЙ для приложения, которого нетшанс, что я когда-нибудь буду использовать его в другом приложении.Таким образом, выгода "легкого повторного использования" минимальна.

Итак, если вы исключите эту выгоду, какой метод на самом деле лучше?(Более производительный, менее ресурсоемкий?)

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

Какой метод лучше использовать?Какие еще плюсы / минусы есть у каждого метода?

Заранее большое спасибо.

Answer 1

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

Это позволяет повторно использовать код и, как правило, более устойчиво с точки зрения жизненного цикла, чем дети, вызывающие функции из своего родителя.,Родители добавляют детей, но дети, вызывающие родителей, подразумевают, что оба объекта должны знать и обрабатывать определения типов.Невозможно изолировать функциональную единицу.

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

Программная реализация должна быть передана вниз с родительским контролем над детьми.События восходят к восходящим.

Дочерние элементы, поддерживающие управление, аналогичны шаблонам IoC (Inversion of Control), похожи на Java Spring или то, что Swiz Framework предоставляет для Flash.

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

События, у которых нет прослушивателей, по существу не имеют служебных данных.

Answer 2

Избегайте, чтобы ваш Dialog знал о классе главного экрана.Тесная связь делает отладку более трудной и не совсем отражает ваше намерение - ваш класс должен только иметь доступ к тому, что ему нужно для выполнения своей задачи.Что-то дополнительное - в лучшем случае дополнительные накладные расходы на отладку, а в худшем - сбивает с толку тех, кто читает код.

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

IDialogDelegate.as

package
{
    public interface IDialogDelegate
    {
        function submitSelected():void;
    }
}

MainScreen.as

package 
{
    public class MainScreen extends Sprite implements IDialogDelegate
    {
         private var _dialog:Dialog;

         public function MainScreen()
         { 
             super();
             _dialog = new Dialog();
             _dialog.delegate = this;
             addChild(_dialog);
         }

         public function submitSelected():void
         {
             trace("handled!");
         }
    }
}

Dialog.as

package 
{
    public class Dialog extends Sprite
    {
        private var _delegate:IDialogDelegate
        private var _submitButton:Button;

        public function Dialog()
        {
            _submitButton = new Button();
            _anExampleActionButton.label = "Submit";
            _anExampleActionButton.addEventListener(MouseEvent.CLICK, onExampleActionSelected, false, 0, true);
            addChild(_anExampleActionButton);
        }

        public function set delegate(value:IDialogDelegate):void
        { _delegate = value; }

        private function onExampleActionSelected(event:MouseEvent):void
        {
            if(delegate != null)
            { delegate.submitSelected(); }
        }
}

Answer 3

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