Donc pour rappel, nous avons a notre disposition une classe Factory qui nous permet de créer des instances d’objets héritant tous d’une interface de base.
i.e. Shape était notre interface Cylinder, Sphere nos instance a créer.

Le désavantage principal de l’implémentation était l’obligation d’écrire dans chaque classe une méthode statique créant l’instance :

static Shape *Sphere::create(void);

Heureusement, les template vont encore une fois nous aider a nous abstraire de cette contrainte.

La factory retourne des objets de type Object (paramètre de la classe templatée) elle stocke pour chaque clef une fonction dont le prototype est :

Object *()(void);

L’idée va être de ne plus stocker une fonction mais un objet au sens C++ jouant le rôle de cette fonction.

Dans notre cas, le foncteur a donc une méthode CreateInstance(void) retournant un Object

template  struct InterfaceCreator{
   virtual Object *CreateInstance(void) = 0;
};

on modifie en conséquence la classe Factory :

template  class Factory{
public:
 
// on redéfinit notre nouveau type comme
// etant un InterfaceCreator<object width="100" height="100" type="application/x-shockwave-flash"></object>

Maintenant, il nous faut specialiser des Creator pour notre Sphere, Shape, etc…

template
class Creator : public InterfaceCreator
{
public:
  BaseClass *CreateInstance(void){
     RealClass instance = new RealClass();
     return static_cast(instance);
  }
};

Petite explication de cette double paramétrisation. Nous avons besoin du type réel de l’objet (Sphere) pour le créer et le type abstrait(Shape) pour pouvoir heriter de InterfaceCreator

Passons a l’utilisation :

Factory shapeFactory;
...
 
class Sphere : public Shape{
  ....
  static bool registered;
};
 
bool Sphere::registered = shapeFactory.register("Sphere", new Creator );
bool Cylinder::registered = shapeFactory.register("Cylinder", new Creator );

j’espère que ca vous aura plu un minimum
a+
Twxs

Dans ce tutorial, je vais tenter d’aborder le design pattern factory (fabrique pour les anglophobes).
A mon habitude, nous allons retrouver la même ligne directrice que pour les précédents tutoriaux.
Je vais commencer par expliquer brièvement le principe de la factory, ensuite en découlera une première implémentation en C++ et enfin on essayera de rendre ça le plus générique possible.

Definition

La factory est en fait un objet dont le rôle est de créer des instances d’autres objets.
Dans un modeleur par exemple, on pourrait avoir une factory d’objets géométriques qui servirait à créer des sphères, cônes, etc…

Première Implémentation :

Nous allons prendre le cas d’une factory d’objets géométriques dont le but est de fournir des objets héritant de l’interface Shape.

class Shape{...};

De plus, nous avons dans l’application des objets implémentant l’interface shape comme Sphere, Cone, ….

class Sphere : public Shape{...};
class Cone   : public Shape{...};

Une premiere implémentation de la factory pourrait donner ceci :

class ShapeFactory{
public:
  Shape * createSphere(void){
    return new Sphere();
  }
  Shape * createCone(void){
    return new Cone();
  }
};

Ce qui donne à l’utilisation :

ShapeFactory factory;
 
Shape * sphere = factory.createSphere();
sphere->display();

Cette première approche fonctionne, mais a le désavantage de rendre le code de la factory dépendant de l’application.
Nous allons tenter de définir la factory de manière générique (template ) afin de pouvoir la réutiliser dans d’autres cas.

On templatise un peu ?

On peut voir la factory comme une map : à une clef donnée, on associe un type d’objet a créer.

On devrait donc avoir au niveau des paramètres de la factory générique, le type de la clef et le type d’objet que la factory retourne. Ceci nous donne le prototype suivant :

template  class Factory;

Et à l’utilisation :

Factory shapeFactory;

De plus, on s’attend à pouvoir écrire quelque chose du genre :

Shape *sphere = shapeFactory.create("Sphere");

On enrichit donc notre esquisse de la classe :

template  class Factory{
public:
  Object * create(key);
}

Pour le corps de la méthode create, nous avons besoin de réellement créer une instance d’un objet que la factory ne connait pas. Comme ceci ne peut pas se faire par magie, il va falloir enregistrer dans la factory une fonction capable de créer chaque objet et les associer à une clef.

template  class Factory{
public:
// un pointeur de fonction qui retourne un Object*
  typedef Object *(*Creator)(void);
 
  map _registeredCreator;
 
  bool register(Key key, Creator creator){
    if(_registeredCreator.find(key) != _registeredCreator.end())
      return false; // la clef est deja utilisé
    _registeredCreator.insert(pair(key, creator));
    return true;
  }
 
  Object * create(Key key){
    Object *object;
    Creator creator;
    map::iterator it;
 
    // on cherche le pointeur de fonction associé a la clef
    it = _registeredCreator.find(key);
    if(it == _registeredCreator.end())
	return NULL; // on ne l'a pas trouvé
 
    // on récupère le pointeur de fonction
    creator = (*it).second;
    // on appelle la fonction pour créer un nouvel objet
    object = (*creator)();
    // on retourne l'objet
    return object;
  }
};

Regardons maintenant comment utiliser tout ça :

// des fonctions de création d'objets
Shape *createSphere(void){return new Sphere;}
Shape *createCone(void){return new Cone;}
 
Factory shapeFactory;
shapeFactory.register("Sphere", createSphere);
shapeFactory.register("Cone", createCone);
 
Shape *sphere = shapeFactory.create("Sphere");

Ici le problème reste la nécessité d’avoir des fonctions « C » à mettre dans le code, et de devoir enregistrer ces fonctions à la main. Donc à chaque ajout d’objet géométrique devoir aller remodifier ce code d’initialisation de la factory.

Pour rendre ceci un peu plus propre, nous allons définir ces fonctions en statique dans chaque objet géométrique et se servir de l’initialisation des CRT pour enregistrer les fonctions automatiquement.

// sphere.h
class Sphere : public Shape{
  static Shape* create(void);
  static bool register;
};

// sphere.pp
#include "ShapeFactory.h" // on considère que la shapeFactory est une variable globale accessible par ce fichier
 
Shape * Shpere::create(void){
  return new Sphere();
}
// auto enregistrement :
bool Sphere::register = shapeFactory.register("Sphere", Sphere::create);

Il est possible d’utiliser des macros pour encore réduire la taille du code à produire.

Petite explication : au lancement du programme, la variable statique register est initialisée. Cette initialisation passe par l’appel de la methode shapeFactory::register qui enregistre le « create ».

Conlusion:

J’ai ici présenté l’implémentation « générique » d’une factory; pour pousser un peu plus l’exemple du modeleur, on peut imaginer que l’interface Shape permette de décrire des attributs (association nom / valeur). Une sphère par exemple aura un paramètre de type float nommé « radius ».
Notre petite application graphique aura à parcourir les entrées de la factory pour y découvrir tous les objets « instanciables » et fournir à l’utilisateur un panel de boutons pour créer des Shapes.
A partir de là, à chaque Shape créé, elle pourra construire une boîte de dialogue d’édition adaptée à l’objet (à la mode 3DS), SANS en connaitre le type réel.

Pour aller plus loin :

Il est possible de s’abstraire de l’écriture de la fonction create statique dans les classes en utilisant les templates pour créer des objets dont le rôle est de remplacer la fonction statique.

A l’utilisation cela donne quelque chose comme :

bool Shape::register = shapeFactory.register ("Shape", Creator() );

Il faut pour cela modifier un peu la classe factory, mais je vous le laisse en exercice (j’ai toujours révé de dire ça un jour…)

Dernier point, on peut utiliser les singleton pour ne pas avoir à stocker la factory dans une variable globale.

joyeuses fetes

Twxs

Cet article provient du tutorial publié par Twxs le 24/12/2004 sur l’ancien site de Coder-Studio.

Introduction

La relation Observer/Observable est un concept assez simple, le principe repose sur le fait de pouvoir informer automatiquement des objets (Observeurs) des modification d’un autre (l’Observable). Nous prendrons comme cas « d’école » l’exemple d’un VU mètre system. On supposera avoir une classe CPU permettant de connaitre la charge cpu, une classe FileSystem donnant accès aux informations concernant les disques et enfin, une classe charger d’afficher l’état de notre machine i.e. la charge CPU et l’occupation des disques.

La classe Observer
L’observer est un objet « simple », être observeur defini uniquement le fait de pouvoir être mis a jour par un objet extérieur. Ceci se traduit par avoir une méthode de type update.
Ceci nous mène à une premiere définition de l’interface Observer :

struct Observer {
  virtual void update() = 0;
};

Rendre un objet observateur d’un sujet, se traduira alors par une implémentation de cette interface. ex :

class VUMeter : public Observer {
  void update(void){
    // mis a jour car un sujet a changé d'etat
  }
};

La première limitation de cette proposition vient du fait que l’on ne prend pas en compte le type du sujet observe dans l’interface. Ceci a l’utilisation, obligera en plus d’hériter de l’interface, de stocker dans ses attributs une référence au sujet. ex :

class VUMeter : public Observer{
private :
  Subject *subjet;
public :
  void update(void){
    // subject a change
    subject->getValues()...
  }
};

une première solution, est de passer en paramètre la classe Observable dans la méthode update.

void update(Observable *subject){
  //
}

cette solution est presque viable, mais va obliger :

• soit a implementer dans l’observable, une interface generique pour récuperer les information d’un sujet « abstrait ». Il nous faudra récuperer la charge CPU, l’occupation du disque…
• soit a « dynamic_caster » le sujet de type Observable en son reel type

void update(Observable *subjet){
  if((CPU *cpu = dynamic_cast(subject)) != NULL){
     cpu->getLoad()...
  }
  else if((FileSystem* fs = dynamic_cast(subject)) != NULL){
    fs->getFreeSpace();
  }
}

Cette solution n’est pas des plus élegantes. Une derniere alternative plus « propre » serait de posseder une méthode update prenant en paremetre un CPU* et une autre prenant un FileSystem*

void update(FileSystem*);
void update(CPU*);

Cette solution nous garantie une separation propre du code. Pour l’implementer, nous allons devoir passer par l’utilisation de template. Le principe : spécifier le type reel observé dans l’interface Observer

template
struct  Observer{
  virtual void update(Subject *) = 0;
};

Et voici maintenant l’utilisation :

class VUMeter :
  public Observer,
  public Observer{
public:
  void update(FileSystem* fs){
    fs->getFreeSpace(...
  }
  void update(CPU* cpu){
    cpu->...
  }
};

Et voila le travail, nous avons un observeur capable d’observer plusieurs sujets. Ils nous reste a implémenter l’autre partie : l’Observable

La classe Observable
Nous devons ici definir la classe de laquelle vont deriver CPU et FileSystem pour être observable. Les besoins d’un Observable sont :

• lui attacher un observateur
• le détacher
• notifier tous les observateurs
• stocker ses observateurs

class Observable{
  std::set _observers;
  void attach(Observer *o); // insertion dans le set
  void detach(Observer *o); // suppression du set
  void notify(void){ // updater tous les observers dans le set
    ...
      obs->update(...)
  }
};

Cette implémentation ne fonctionne pas a cause de la « templatisation » de la class Observer qui prend, déjà, pour la méthode update le type réel du sujet (ex : FileSystem) mais aussi par le fait que les observeurs n’héritent pas de Observer, mais Observer.
Dans la classe Obserable, nous devons donc connaitre le type reel du sujet.
Encore une fois les template vont permettre de nous en sortir :

template  class Observable
{
public:
  ~Observable(void);
  void attach(Observer *o);
  void detach(Observer *o);
  void notify(void);
private:
  std::set<Observer *> _observers;
};

A l’utilisation, ceci donne :

class FileSystem : public Observable{
   ...
   void some_func(){
     ...
     notify(); // on change d'etat, informer les observateurs
   }
   ...
};
 
VUMeter vum;
 
FileSystem fs;
CPU cpu;
 
cpu.attach(&vum);
fs.attach(&vum);

Et Voilà, c’est fini!

Cet article provient du tutorial publié par Twxs le 03/11/2004 sur l’ancien site de Coder-Studio.

Prenons un exemple:

glEnable(flag);
....
glDisable(flag);

C’est ici l’utilisation normale d’opengl. Rien de compliqué mais c’est exactement ce qu’on veut éviter pour ne pas alourdir le code…

Un premier pas vers le RAII

struct Enable{
   Enable(GLenum flag){
      glEnable(flag);
   }
 
   ~Enable() {
      glDisable(flag);
   }
};

Puis on l’utilise dans un bloc, comme suit :

{
   Enable active(flag);
   ...
}

Comme on peut le voir ici, Le principe est très simple : Lors de la création de l’instance de la structure Enable, on execute via le constructeur la commande opengl glEnable(). Lorsque l’on sort de la zone de portée de cette instance (ici, le bloc {}), elle est détruite. Il y a donc appel du destructeur dans lequel on a placé la commande glDisable().

Conservation et propreté

Cette première version fonctionne, mais imaginons qu’avant le bloc le flag soit deja activé : à la sortie il sera desactivé. Pour s’assurer de la récuperation d’un contexte identique, nous devons modifier notre classe pour mémoriser l’etat courant avant sa modification.

On procède de cette manière :

struct Enable {
 
   GLboolean state;
   Enable(GLenum flag) {
      state = glIsEnable(flag);
      // State contient l'état actuel du flag
      // Si le flag est deja activé il n'est pas necessaire de le réactiver
      if(!state)
         glEnable(flag);
   }
 
   ~Enable() {
      // Si le flag était désactivé à la création de la classe on le désactive à nouveau
      if(!state)
         glDisable(flag);
   }
};

Ici nous sommes : L’utilisation de l’objet conserve le contexte opengl.

Cas d’usage : factorisation du code à l’aide des templates

Prenons le cas suivant :

{
   Enable lighting(GL_LIGHTING);
   Enable light0(GL_LIGHT0);
   Enable depth(GL_DEPTH_TEST);
 
   // ...code
}

Supposons que ces trois appels reviennnent régulierement : l’héritage multiple devrait nous permettre de factoriser ce code en regroupant le tout en une seule et même classe. Mais le probleme ici, c’est que nous avons une unique classe pour tous les états. Comme nous ne pouvons pas heriter plusiseurs fois de la même classe, il va falloir trouver une autre solution.

Et celle qui s’y prête le mieux reste l’utilisation de templates :

template struct Enable {
   GLboolean state;
   Enable() { //plus de paramètre au constructeur
      state = glIsEnable(Flag);
      // state contiend l'etat actuel du flag
      // si le flag est deja active il 'est pas necessaire de le reactiver
 
      if(!state)
          glEnable(Flag);
   }
 
   ~Enable() {
      if(!state)
      glDisable(Flag);
   }
};

En « templetant » la classe Enable, nous obtenons une classe différente pour chaque paramètre du template, et donc pour chaque flag.

Au niveau de l’utilisation,

Enable depth(GL_DEPTH_TEST);

deviendra :

Enable depth;

Mais surtout, ceci va nous permettre de factoriser des états.
Reprenons les trois appels redondant de notre programme :

Enable lighting;
Enable light0;
Enable depth;

En templatant, on peut créer une structure héritant de chaque classe :

struct MonContext :
   Enable ,
   Enable ,
   Enable
{
};

Nous obtenons une structure ayant les propriétés de 3 classes parents. Et surtout, à la creation de l’objet les 3 constructeurs des parents seront appelés, et réciproquement à la destruction.
On peut donc se contenter de ceci :

{
   MonContext ctx_light;
}

Conclusion

Voilà pour l’utilisation des RAII : Rien de très complexe dans la théorie ou dans la pratique. C’est par contre un puissant outil qui devrait rapidement devenir indispensable à la clarté de tout programme conséquent.
Un grand merci à Twxs pour ce tuto !

Cet article provient du tutorial publié par Twxs le 03/10/2004 sur l’ancien site de Coder-Studio.