Flash AS3 RIA開発のより良いプラクティス-イベント/リスナーを使用するか、子供が親の関数を呼び出すことを許可しますか?

actionscript-3 flash flex
Flash AS3 RIA開発のより良いプラクティス-イベント/リスナーを使用するか、子供が親の関数を呼び出すことを許可しますか?

私はFlash AS3で構築されたWebアプリに取り組んでいます。

高レベルでは、アプリにはメイン画面と、さまざまなユーザーインタラクションを管理するためにポップアップするいくつかの「モーダルダイアログ」タイプの画面があります。

(これは、私が開発するほとんどのアプリで使用する同様のパターンです…​)

通常-ユーザーがダイアログ画面(ボタン、テキストボックス、スライダーバーなど)でUIコントロールをクリックすると、メイン画面は反応するか、結果を管理する必要があります。

これを処理する一般的な方法は2つあるようです。

  1. メイン画面がリッスンするイベントをダイアログ画面にディスパッチさせる
    for

  2. ダイアログ画面がメイン画面の機能を呼び出すことを許可します
    これらのコントロールをクリックします(ダイアログ画面がメイン画面への参照を維持し、メイン画面の機能がパブリックであることが必要です)

一般的に-最初の方法の主な利点の1つは、ダイアログ画面がそれほど密に結合されていないことです。唯一の責任は、イベントをブロードキャストすることです。 これにより、他のコンテキストまたはアプリケーションでダイアログクラスをより簡単に使用できるようになります。

しかし、私が開発する多くのRIAにとって、特定の画面は、アプリケーションにとっては* SO SPECIFIC *であり、別のアプリケーションで再利用する可能性はまったくありません。 したがって、「簡単な再利用」の利点は最小限です。

だから-あなたはその利点を排除する場合-どの方法が実際に優れていますか? (パフォーマンスが向上し、リソースの消費が少なくなりますか?)

たとえば、イベントを使用する場合、Flashは、発生しない可能性のあるイベントの多くのリスナーを管理する必要があります。 そのため、ダイアログウィンドウがイベントをディスパッチする代わりに、メイン画面の関数を直接呼び出すことができれば、より効率的です。

どの方法がより良い方法ですか? 各方法には他にどのような利点/長所/短所がありますか?

事前に感謝します。

  3  0


ベストアンサー

MVCパターンと多くの開発者は、イベントを介したロジックの分離は優れたパターンであると主張します。

これによりコードの再利用が可能になり、一般にライフサイクルの点で、親から関数を呼び出す子よりも安定しています。 親は子を追加しますが、親を呼び出す子は両方のオブジェクトが型定義を認識して処理する必要があることを意味します。 機能単位を分離する方法はありません。

おそらくあなたの実装はあまりにも具体的であり、より多くの機能を抽象化すると、引用するよりも多くの再利用が可能になります。 大規模なプロジェクトでは、純粋な手続き型パターンの管理が困難になる複雑性にすぐに到達する可能性があります。

プログラムによる実装は、親が子の制御を維持したまま下方に渡す必要があります。 イベントは上位にバブルアップします。

制御を維持する子は、IoC(制御の反転)パターンに似ており、Java SpringまたはSwiz FrameworkがFlashに提供するものに似ています。

関数はより高速に実行されます。ただし、パターンを実行する何千ものクラスについて話さない限り、あなたが話すオーバーヘッドは最小限です。 その場合、シングルトンエンジンは実装の高速化に役立ちます。

リスナーを持たないイベントには、基本的にオーバーヘッドはありません。

5


メイン画面クラスについてダイアログに知らせることは避けてください。 密結合はデバッグをより困難にし、あなたの意図を真に代表するものではありません-クラスはそのタスクを達成するために必要なものにのみアクセスできるべきです。 追加するものはせいぜい追加のデバッグオーバーヘッドであり、最悪の場合、コードを読む必要がある他の人にとっては混乱を招きます。

AS3イベントディスパッチシステムのパフォーマンスへの影響が心配な場合(毎秒数百のイベントをディスパッチしない限り、そうすべきではありません)、代わりにデリゲートパターンを使用してください。 ハード参照を使用するため、非常に高速で(メイン画面を直接渡すのに簡単に匹敵します)、依然として疎結合モジョを提供します。 Dialogは、メッセージを送信するクラスを認識しません。 オブザーバー/リスナーパターンと比較した場合の欠点は、単一の「リスナー」しか取得できないことです。 パターンの例を次に示します。

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(); }
        }
}

2


冒険的で、ランタイムエラーが好きな場合は、コールバックとして使用する関数を渡すこともできます。 関数を親から子に渡し、必要に応じて子が関数を呼び出します。

1


タイトルとURLをコピーしました