Deux mois se sont écoulés depuis la publication de la pseudo préface de ce dossier ambitieux sur les design patterns en ActionScript 2.0.

Voici enfin aujourd’hui la première partie, chargée d’introduire les modèles de création et d’exposer au grand jour le pattern Singleton.

Une petite mise en garde de rigueur avant de commencer :

Pour aborder cette série d’articles, il est indispensable que vous possédiez déjà des connaissances de base en programmation orientée objet.

Maîtriser la syntaxe ActionScript 2.0 sera biensûr un atout majeur qui vous permettra de décortiquer les exemples donnés tout au long des différents dossiers.

En dernier préambule, j’aimerai insister aussi sur le fait que la plupart des patterns prennent vraiment tout leur sens lorsqu’ils sont employés à l’intérieur de véritables applications ou plutôt … Laissez moi reformuler ma phrase : L’intérêt de chaque pattern devient évident et limpide lorque l’on s’est déjà heurté au problème dont il se propose d’être le remède. Pour résumer, c’est quand on commence à se confronter aux réelles difficultés liées au développement que ces élégantes abstractions deviennent limpides. Il est en effet souvent très difficile (voir impossible) de cultiver la robustesse, la sécurité, la durabilité ou l’évolutivité du code sans recourir à toutes ces bottes secrètes. Cet apprentissage (comme la plupart) peut biensûr se dérouler de façon totalement intuitive tout au long des expériences de chacun. Passer par la théorie c’est se donner des chances supplémentaires de voir clair vite et bien.

En général un modèle de conception se décompose en quatre parties :

- Le nom

- Le problème

- La solution

- Les conséquences

Ces caractéristiques portent des noms assez explicites pour m’éviter la rédaction inutile d’un glossaire pompeux et redondant. Si tel n’était pas le cas, je reste persuadé que les explications qui suivront vous aideront à mettre en lumière leur vocation respective.

La première famille de modèles que nous allons donc aborder est spécialisée dans la création, comprenez par là : Processus d’instanciation.

Il s’agit des modèles créateurs.

L’intérêt majeur de cette famille, c’est de privilégier l’abstraction d’un processus de création plutôt que de coder celui-ci en dur et se heurter par là même (tôt ou tard) à une inertie écrasante du système, que je qualifierai (avec humour) de fossilisation irréversible de l’application.

Pour prendre une image du monde réel (encore une), il est plus facile en tant que patron d’un hôtel d’employer un cuisinier pour répondre à l’attente de ses clients concernant leur appétit et goûts respectifs, plutôt que de laisser la possibilité à chacun de se restaurer en mettant à disposition locaux, ustensiles recettes et provisions de l’établissement. Il n’est pas besoin d’être un savant informaticien pour cerner les problèmes de logistique engendrés par la deuxième solution.

Offrir la reponsabilité à une entité de s’occuper de la création de chaque plat en s’adaptant à la demande de notre aimable clientèle ainsi qu’aux contraintes imposées par le système (stock, coûts …) nous permet non seulement d’occulter la fabrication des plats mais aussi d’interchanger le détenteur de cette responsabilité selon nos besoins ou exigences (grand chef cusinier pour les soirées V.I.P contre équipe d’apprentis pour les grands rushs de midi).

Pour résumer, le principe fédérateur de cette famille de patterns, c’est d’encapsuler la connaissance des classes concrètes (recette de chaque plat) que le système (hôtel) utilise et masquer le déroulement et le paramétrage d’une instanciation (fabrication d’un plat).

Pour commencer, voici la liste des patterns appartenant à cette famille de modèles (modèles créateurs) :

- Fabrique abstraite

- Monteur

- Fabrication

- Prototype

- Singleton

Nous allons commencer cette étude par un patterns très utilisé, j’ai nommé le Singleton.

Il est souvent important au sein d’une application de pouvoir s’assurer premièrement de l’unicité d’un objet, deuxièmement de son accessibilité à tout moment par les autres objets de l’application sans avoir recours à des références multiples.

Comme un exemple est souvent beaucoup plus parlant qu’une longue explication technnique, nous allons illustrer l’utilisation de ce pattern en nous appuyant sur une situation concréte. Pour les besoins de cette démonstration nous allons créer une classe abstraite Connection dont le rôle sera de créer une connexion socket entre le client Flash et un serveur unique prédéfini.

Vous conviendrez au vu de l’énoncé qu’il serait maladroit voir catastrophique d’avoir des instances multiples de Connection.

En utilisant le pattern Singleton sur notre classe Connection nous garantissons le fait qu’il ne peut y avoir qu’une seule instance de connexion dans notre application.

Cerise sur le gâteau ce pattern fournira un point d’accès unique et global à tous les éléments de notre application nécessitant les services de celle-ci.

// Classe fictive pour illustrer le déploiement du pattern Singleton

class Connection
{
 	// Membre statique protected (faute de pouvoir être placé en privé)
 	// servant à stocker une référence de notre connection, .
 	private static var _oInstance:Connection;

 	// Le constructeur est placé en protected.
 	// Ceci garantit déjà l'impossibilité d'instancier directement une connection
 	// sans passer par le point d'accès.
     private function Connection()
 	{
  		trace("Constructeur appelé");
  	}

 	// L'unique point d'accès qui empêche toute duplication.
     public static function get instance() : Connection
     {
  		// Pour créer une connection (instance de Connection)
  		// On s'assure que celle-ci n'existe pas déjà.
  		if (_oInstance == undefined) _oInstance = new Connection();
  		// Dans tous les cas, on retourne une référence vers l'objet
  		// à celui qui en a fait la demande.
  		return _oInstance;
      }

 	// On prévoit une méthode pour détruire notre instance
 	// en cas de besoin de réinitialisation
 	// ou de libération de la mémoire.
 	public static function release() : Void
 	{
  		// Si l'instance existe on la détruit.
  		if (_oInstance)
  		{
   			trace("instance détruite");
   			delete _oInstance;
   		}
  	}

 	// Maintenant que le pattern est déployé voici le coeur
 	// de notre objet exposé avec ses différentes méthodes :
 	public function connect() : Void {}
 	public function disconnect() : Void {}
}

Note : Le fait que le player Flash ne gére pas le muti-threading nous protège des soucis d’initialisation différée comme dans certains langages comme C++.

La question légitime que l’on est maintenant en droit de se poser face au modéle Singleton c’est pourquoi ne pas passer en statique toutes les méthodes comme je le fais avec la SoundFactory ?

Les deux seuls avantages en ActionScript à retirer sont :

- D’avoir plusieurs instances d’une classe mère par extensions multiples. – D’avoir la possibilité en cours de développement de modifier le design parceque l’on s’aperçoit que l’on nécessite finalement plusieurs instances de la même classe.

Voici pour finir une fiche technnique pour résumer les caractéristiques du modèle Singleton :

Nom : Singleton

Le problème : S’assurer de l’unicité de l’instance d’une classe

La solution :

- Définir un membre privé static pour stocker l’instance.

- Définir une méthode publique pour accéder à celle-ci.

- Mettre le constructeur en protected (private en AS 2.0).

Les conséquences :

- Contrôle d’accès à l’instance régulé.

- Changement de stratégie possible à tout moment.

Et pour accompagner ce résumé voici une implémentation générique du pattern Singleton en ActionScript 2.0 :

class Singleton
{
 	private static var _oInstance:Singleton;

     private function Singleton() {}

     public static function getInstance() : Singleton
     {
  		if (_oInstance == undefined) _oInstance = new Singleton();
  		return _oInstance;
      }

 	public static function release() : Void
 	{
  		if (_oInstance) delete _oInstance;
  	}
}

Le prochain article traitera du modèle fabrique abstraite. En attendant n’hésitez pas à me faire partager vos éventuelles questions ou commentaires.

Les fichiers source sont disponibles ici.