Singleton héritable ?

**rolkA** · 09/12/2004, 21h31

Bonjour,

1. J'aimerais (tout simplement ?) savoir comment faire un singleton pouvant être hérité. Après une brève recherche je n'ai rien trouvé de concluant, car je tombe toujours sur des implémentations ne permettant pas de dériver. Mais est-ce possible ? J'ai beau me creuser la tête je n'arrive pas à voire comment je pourrais faire. Surtout si je veux qu'il puisse être hérité plusieurs fois, çàd avoir des petits-fils.

2. J'ai un autre problème, c'est la gestion d'un constructeur avec paramètres pour un singleton: si je veux une création transparente du singleton à travers sa méthode "instance()", mais que la construction requiert des paramètres que seules certaines des classes utilisatrices du singleton possèdent, comment faire ?

Merci d'avance, j'espère avoir été assez clair (rien n'est moins sur)

PS: je n'ai pas précisé que je reste cantonné au C++, mais bon, vu le forum choisi, vous aurez deviné

**Luc Hermitte** · 09/12/2004, 23h04

J'avais fini par laisser tomber les singletons à hériter. Dans mes souvenirs j'avais un mélange en "template curieusement récurrent" et amitié, design que je ne trouvais pas excessivement pratique.

Résultat aujourd'hui j'utilise des fichiers-squelettes (via un plugin que je maintien pour vim ; il doit y avoir des solutions similairesaveclesautres éditeurs de code) qui permettent de définir rapidement des singletons simples (ceux avec la variable locale statique). Pour les singletons plus compliqués, je regarde du côté de Modern C++ Design (qui décore une classe normale pour lui rajouter un aspect singleton), ou ACE (qui dans mes souvenirs définit des singletons héritables qui sont enregistrés dans un Lifetime Manager).

Si tu veux définir un singleton avec paramètres, en général cela veut dire qu'à un moment précis tu sais comment sera construit le singleton. Et bien à ce moment là tu le construis (avec une fonction membre statique spéciale), ou bien tu le construit (avec un constructeur) et l'enregistre aussitôt dans un objet qui centralise les singletons de ton application.

**rolkA** · 10/12/2004, 00h38

Je devrais donc redéfinir chaque classe fille comme étant un singleton ?
En redéfinissant, entre autres, une méthode 'instance()' statique ?
Mais alors le pêre risque de ne plus être un vrai singleton....
Par exemple, si Pere::instance() est appelé, et qu'ensuite, Fils::instance() est appelé, alors Fils va construire un pêre, ce qui donne deux instances de Pere dans le programme.
meme problème si plusieurs fils.

Bref, peux-tu détailler ta façon de faire ? Je n'ai pas saisi ta façon "rapide" de définir des singletons.

**Caine** · 10/12/2004, 08h36

Tiens manière que je me rafaichisse la mémoire, un lien vers le singleton, car ça fait des années que je n'ai pas entendu ce terme.

D'avance merci

**Gandalf** · 10/12/2004, 09h57

Je pense qu'en faisant un singleton en utilisant un pointeur static (et non la variable static dans la methode instanciatrice) et des constructeurs protected et non private...

Du coup les classes filles peuvent appeller les constructeurs de la classe singleton. et si leur methode d'instanciation set la valuer du pointeur, il n'y a pas problème :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
class SingletonPere
{
   public:
   static SingletonPere* GetInstance();
   virtual ~SingletonPere();   ///< Pour etre plus propre vis à vis de l'heritage. Mais attention où le placer en fonction de qui doit pouvoir detruire le singleton...
   protected:
   SingletonPere();
   static SingletonPere* Self;
}
 
class SingletonFils
{
   public:
   static SingletonFils* GetInstance();
   private:   ///< donc plus heritage possible ensuite
   SingletonFils();
   static SingletonFils* Self;
};
 
SingletonPere* SingletonPere::Self=NULL;
SingletonFils* SingletonFils::Self=NULL;
 
SingletonPere* SingletonPere::GetInstance()
{
   if(!Self)   ///< SingletonPere::Self forcement
      Self = new SingletonPere();
   return Self;
}
 
SingletonFils* SingletonFils::GetInstance()
{
   if (!Self)   ///< SingletonFils::Self forecement !
   {
      if(SingletonPere::Self) ///< !Aie! Problème le pere existe déjà
      {
          delete SingletonPere::Self; ///< Un peu radical ? Un autre solution est de renvoyer NULL, a adapeter en fonction des besoins
      }
      SingletonPere::Self = Self = new SingletonFils(); ///< SingletonPere:: Self aussi comme cela SingletonPere::GetInstance renvera vous savez quoi !
   }
   return Self;
}

**tut** · 10/12/2004, 10h06

je pense que Luc utilise un squelette de fichier avec déclaration de classe, de la fonction qui retourne l'instance, et la petite variable statique... quand tu veux un singleton tu dupliques ton fichier.

un lien :
http://www.dofactory.com/Patterns/PatternSingleton.aspx

**Luc Hermitte** · 10/12/2004, 12h21

Oui, c'est ça

Sinon, une hiérarchie de singletons me parait bizarre -- je viens juste de comprendre la question originale. Je croyais que tu cherchais un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
template <class T>
struct singleton { 
    T & instance(){ static T s; return s; }
private: // les constructeurs & co ....
};
 
class S : public singleton<S> 
{
    friend struct singleton<S>;
....
};

Bref. En fait, il faut se demander ce qui est important. Est-ce :
- d'avoir des classes dont on ne peut récupérer l'unique instance que via la fonction membre statique instance() ?
- ou d'avoir des classes dont on peut récupérer l'unique instance via la fonction membre statique instance() ?

Je dirais que c'est le second aspect le plus important.

Pour ce qui est de la construction avec une valeur, sort une autre fonction membre statique (si tu utilises l'attribut membre statique de type pointeur), et passe par une phase de préparation dans ton application dans laquelle tous tes singletons sont créés. Tu peux aussi garder cette phase d'initialisation et utiliser un centraliseur d'objets auquel tu demanderas tes singletons.

**rolkA** · 10/12/2004, 12h42

Merci pour vos réponses.
En effet je veux une hiérarchie de singleton, je vais étudier le code de Gandalf et je reviendrai

Edit: ok çà va, j'ai un peu adapté le code de Gandalf... Seulement, je ne peux pas faire un template Singleton + un système d'héritage qui marche (pour utiliser ensuite l'héritage multiple "est un singleton" + "est un SingletonPere"), à moins de bidouiller énormément. Je dois donc réécrire à chaque fois tout ce qui concerne la gestion d'un singleton, dans chaque classe. J'ai créé un modèle de code à copier-coller.
Merci à tous. A+

**rolkA** · 11/12/2004, 12h22

Envoyé par Luc Hermitte

Oui, c'est ça

Sinon, une hiérarchie de singletons me parait bizarre -- je viens juste de comprendre la question originale. Je croyais que tu cherchais un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
template <class T>
struct singleton { 
    T & instance(){ static T s; return s; }
private: // les constructeurs & co ....
};
 
class S : public singleton<S> 
{
    friend struct singleton<S>;
....
};

Ca, c'est ce que j'ai déjà, et que j'ai dû abandonner (cf message précédent) pour pouvoir faire une hiérarchie de Singletons (c'est bizarre ?).

Pour ce qui est de la construction avec une valeur, sort une autre fonction membre statique (si tu utilises l'attribut membre statique de type pointeur), et passe par une phase de préparation dans ton application dans laquelle tous tes singletons sont créés

ok je fais comme çà car c'est ce qui me paraît le plus propre. Si l'initialisation n'a pas été faite alors que getInstance est appelée, je lance une exception. Cependant, çà fait un test de plus. Je ne sais pas si c'est légitime.