2010-09-24 4 views
0

Je me demande ce qui serait considéré comme la meilleure pratique pour cela. C'est assez inconséquent, mais je m'intéresse aux opinions des gens.Bonne pratique ici en ce qui concerne les événements

Nous avons deux classes - TitleBar et TemplateMain. TitleBar est une barre en haut de l'écran qui affiche le titre du projet et plusieurs boutons (paramètres, impression, plein écran, etc.) que le TemplateMain devra écouter pour exécuter les fonctions pertinentes. À l'heure actuelle, le modèle écoute pour le clic MouseEvent et utilise ensuite une instruction switch pour obtenir la cible initiale de l'événement, par exemple:

protected function onTitleBarClick(e:MouseEvent):void { 
    switch (e.target){ 
    case (titleBar.settingsButton): 
      addSettings(); 
      break; 

    //  etc.. 

    } 
} 

Y aurait-il un avantage ou est-il souhaitable de porter ce dans une mesure système d'événements, soit en étendant la classe d'événements native, soit même en tant que signaux as3, de sorte que la barre de titre possède l'écouteur de clic, puis distribue un événement que TemplateMain détecte et agit ensuite en conséquence? Un aspect négatif de ce que je peux voir est que, avec l'écouteur de clic de souris, je finirais avec six autres écouteurs pour les événements faits sur commande. Comme je l'ai dit, peut-être que cela n'a pas d'importance, mais j'aimerais savoir comment les autres gèrent cette situation très commune.

Répondre

0

Personnellement, je préfère rester le plus près possible du principe de la « boîte noire » où un composant a besoin de savoir aussi peu que possible d'un autre composant.

Je voudrais aller pour définir les événements dans la barre de titre. Lorsque TemplateMain reçoit un événement, il n'a pas besoin de savoir d'où vient l'événement, juste ce qu'il est et comment y réagir. Cela vous donne quelques options, vous pouvez utiliser un objet répartiteur, ou le TitleBar lui-même peut être le répartiteur, bien que je préfère toujours quand les composants sont faiblement couplés. En fin d'écoute d'événement, l'utilisation d'un seul gestionnaire ou de nombreuses fonctions dépendra vraiment du contenu de vos fonctions. j'irais pour la clarté & lisibilité. Je ne vois pas l'intérêt de créer une fonction pour un seul paquebot, dans ce cas, je préférerais l'instruction switch. Comme pour créer un certain nombre d'auditeurs, je ne vois pas cela comme un problème, il vous permet de supprimer facilement l'un ou l'autre en fonction de la durée de vie de la fonction.

0

Vous pouvez utiliser un événement personnalisé ou un événement normal, mais vous n'avez pas vraiment besoin de six écouteurs différents. Transformez l'argument event en générique, puis testez le "type" de l'événement. Par exemple:

protected function onTitleBarClick(event:Event = null) : void { 
    if (event is MouseEvent && event.type is MouseEvent.CLICK) { 
    if (event.target is titleBar.settingsButton) { 
     // statements 
    } 
    if (event.target is titleBar.someOtherButton) { 
     // statements 
    } 
    } 
    if (event is MyCustomChangeEvent && event.type is MyCustomChangeEvent.SOME_TYPE) { 
    // statements, etc. 
    } 
} 

En général, cependant, il est préférable de briser vos gestionnaires et ne pas essayer d'avoir un gestionnaire omnibus.

+0

pas sûr du but de mélanger les deux solutions là .. – hamishtaplin

1

Je vous recommande de prendre la route simple et directe pour attacher directement les gestionnaires TemplateMain aux différents boutons. Si vous ne voulez pas créer une relation étroite entre les deux, utilisez un courtier séparé ou quelque chose pour enregistrer les gestionnaires d'événements.

class TemplateMain { 
    function addSettings(...) { } 
    function doSomethingElse(...) { } 
    function doAnotherThing(...) { } 
} 

class Broker { 
    function registerHandler() { 
    titleBar.settingsButton.addEventHandler("click", templateMain.addSettings); 
    titleBar.somethingElseButton.addEventHandler("click", templateMain.doSomethingElse);  
    titleBar.anotherThingButton.addEventHandler("click", templateMain.doAnotherThing); 
    } 
} 
+0

Pourquoi le recommanderiez-vous? Je pensais qu'il était préférable de minimiser le nombre d'auditeurs d'événements d'où mon approche actuelle. – hamishtaplin

+0

@dr_tchock, j'ai vu des gens faire ce que vous faites, mais ce n'est pas bon. Il ajoute du code supplémentaire qui doit être exécuté chaque fois qu'un événement est déclenché et totalement inutile. Les gestionnaires séparés sont également plus faciles à comprendre et à maintenir - chaque petite fonction ne fait qu'une chose.Dans l'ancien et l'ancien temps de Flash, il était très courant d'utiliser un seul gestionnaire pour tout, car Flash ne prenait pas en charge les fermetures, mais cela a été résolu par les classes de fermeture générées par ActionScript dans Flash MX 2004. –