S'inscrire |

 
TEAM
Avatar de Smike
Smike est déconnecté Smike est un Homme 05/02
XP de Smike 3 419 Nombre total de messages de Smike
Voir le profil Facebook de Smike Voir le compte Twitter de Smike Voir le compte DeviantART  de Smike
Administrateur
  #1 (permalink)  
Vieux 05/04/2007, 12h49
Zoom [ActionScript] L'implémentation et l'Eventdispatcher

Nous avons vu que la classe EventDispatcher permettait de gérer (envoyer/recevoir) des messages au cours de nos applications. Dans la classe SpaceShip, nous avons implémenté cette technique en initialisant le EventDispatcher dans le contructeur de notre classe.
Rappelez vous :

ActionScript Code:
  1. function SpaceShip(){
  2. EventDispatcher.initialize(this);
  3. }

Donc à chaque fois que l'on va créer une instance de notre "vaisseau", on va initialiser notre gestionnaire d'évènement. Il est possible de faire autrement.

En effet, comme dans tous les langages, les implémentations peuvent être diverses et variées. Voyons 3 possibilités d'implémenter notre gestionnaire d'évènement.
Ces techniques sont différentes, mais le résultat reste le même. Les performances peuvent par contre variées de l'une à l'autre et suivant leur utilisation. D'autres techniques peuvent très être possibles, et celles présentées ne représentent pas une fin en soi.


Initilisation via le contructeur de la classe
Cette technique à été utilisée dans les articles précédents. On initialise le EventDispatcher dans le contructeur de notre classe.

ActionScript Code:
  1. function SpaceShip(){
  2. EventDispatcher.initialize(this);
  3. }

Ce qui a pour effet direct de "tranformer" notre classe en envoyeur de messages (d'évènements). C'est donc notre classe qui est responsable de l'envoi. C'est d'ailleur ce que l'on montre en réalisant :

ActionScript Code:
  1. dispatchEvent({type: "_onReady", target: this});

La méthode dispatchEvent est appelée directement depuis notre classe.

Avantages :
  • Utilisation classique
  • Code lisible et compréhensible

Inconvénients :
  • A chaque instance de notre classe, on va initialiser notre EventDispatcher.

En terme de performance, n'est pas forcemment une bonne chose. Surtout si l'on décide de créer une véritable flotte intergalactique…
  • Nous somme obliger de déclarer les différentes variables propres au EventDispatcher afin de pouvoir les utiliser.

ActionScript Code:
  1. public var dispatchEvent:Function;
  2. public var addEventListener:Function;
  3. public var removeEventListener:Function;

L'utilisation d'une Interface est ici impossible, je rappel qu'un interface ne défini qu'un "modèle" de méthodes.


Initialisation statique de la classe
Ces autres techniques est née de l'un des inconvénient de la première. L'initialisation systématique du EventDispatcher à chaque création d'une instance de la classe. Pour réaliser ce "hack", nous allons nous servir des variables statiques. Comme nous l'avons vu précédemment, une variable statique est propre à la classe et non pas à son instance.

Pour initialiser une et une seule fois, pour notre classe, notre gestionnaire d'évènement, nous allons réaliser son initialisation dans une variable statique de notre classe.

ActionScript Code:
  1. private static var _oED = EventDispatcher.initialize(SpaceShip.prototype);

Et bien entendu, on supprime l'initialisation du constructeur

Avantages :
  • L'initialisation ne se fait qu'une fois pour la classe (et non pas pour chaque instance créé).

Inconvénients :
  • Le status deprecated de la méthode d'initialisation.

En effet, comme vous le remarquez, l'initialisation se fait sur le prototype de la classe.
N'oublions par que même en réalisant de la Programmation Objet, Flash est toujours basé sur les prototypes. Toutes les classes, interfaces, ..., finissent par être compilée sous forme de prototypes. Ceci dit, il est important de prendre en compte les possibles évolutions de Flash.
Et rien ne dit que Flash ne sera basé sur des classes plutot que des prototypes dans un futur proche. Donc le problème, si ça arrive, on sera obligé de re-coder toute nos classes utilisant cette technique. La déclaration des fonctions "adEventListener, ..." est toujours obligatoire.



Utilisation de la Composition
La notion de composition est nouvelle. Elle sera abordée plus en details dans un prochain article. On oppose la notion de composition à la notion d'héritage en POO. Donc, en toute logique, on evite d'hériter d'une classe mère dans la définition de la classe fille.

Pour ce qui est de notre EventDispatcher, nous allons donc plus déclarer notre classe comme source des évènements (EventDispatcher.initialize(this)), mais plutot utiliser un objet dans notre classe, qui sera notre source d'évènement.
Ainsi, ce n'est plus notre classe qui sera "directement" responsable des envois de messages. Toutes les actions, sur nos évènements, se feront par le biais de notre objet. Quels sont les avantages ? vous le verez dans la suite....
Implémentation en composition de notre gestionnaire d'évènement :

ActionScript Code:
  1. class SpaceShip
  2. {
  3.  
  4. private var _oED:Object
  5. function SpaceShip() {
  6. _oED = new Object();
  7. EventDispatcher.initialize(_oED);
  8. }
  9.  
  10.  
  11. public function registerEventListener(e, oL) {
  12. _oED.addEventListener(e, oL);
  13. }
  14.  
  15. public function removeEventListener(e, oL) {
  16. _oED.removeEventListener(e, oL);
  17. }
  18.  
  19.  
  20. public function doControl():Void {
  21. _oED.dispatchEvent( {type:"onReady", target:this} );
  22. }
  23.  
  24. }

Comme vous le constatez, nos évènements passent systématiquement par l'objet _oED. Dans le code principal de notre application, les abonnements aux évènements sont aussi différents. Pour abonner un écouteur à un évènement, il faudra maintenant faire :

ActionScript Code:
  1. vaisseau.registerEventListener("onReady", this);

Avantages :
  • On perd le status deprecated de la version 2
  • Design très soigné, meilleure lisibilité
  • Plus besoin de déclarer les fonctions addEventListener, ...

Inconvénients :
  • Initialisation du EventDispatcher à chaque instance/


Conclusion
Cet article n'est pas là pour démontrer quelle méthode est la plus appropriée. L'utilisation de telle ou telle méthode depend du desgin choisi. Il est vrai que la 3eme version est très interessante, même si elle demande un peu plus de développement.

En ce qui concerne le gain/perte de performance entre les versions, est très subtile.
Il faudra vraiment développer une application très complexe avant de voir une différence notable. Bien entendu, cette liste est non exhaustive et d'autres techniques peuvent également être utilisés.

Source : Adddvance.net
Réponse avec citation
Réponse

Outils de la discussion

Config des règles de ce forum
Règles de messages
Vous ne pouvez pas créer de nouvelles discussions
Vous ne pouvez pas envoyer des réponses
Vous ne pouvez pas envoyer des pièces jointes
Vous ne pouvez pas modifier vos messages

Les balises BB sont activées : oui
Les smileys sont activés : oui
La balise [IMG] est activée : oui
Le code HTML peut être employé : non
Trackbacks are oui
Pingbacks are oui
Refbacks are oui


A propos d'IK

Infographik alias IK est un forum d'entre-aide dans le domaine de l'infographie numerique
Depuis plus de 10 ans ce forum propose des tutoriaux un espace communautaire francophone.

We need You !

Faire un don permet de régler les frais de fonctionnement du site tel que l'hebergement, le ndd etc...
Faire un don

Fuseau horaire GMT +2. Il est actuellement 02h31.