Discussion :

[gege2061]

Bonjour,

Je cherche à créer une classe singleton qui nécessite des paramètres pour sa construction.

Bien sûr je peux créer une méthode get_instance avec des paramètres et ensuite les transmettre au constructeur, mais une fois le singleton créé ces paramètres deviennent inutiles.

Je pense simplifier les appels ultérieur à la méthode get_instance avec des valeurs par défaut.

Le problème c'est que même si l'utilisateur modifie ces paramètres lors d'un second appel, le singleton étant créé, il n'est pas possible de les prendre en compte.

De ce que j'ai vu, le paramètre d'un singleton est plus utiliser pour modifier le comportement de la méthode get_instance (par exemple pour retourner un élément donné d'une liste).

Une idée ?

[Anthony.Desvernois]

Je ne comprends pas trop ce que tu cherches à faire exactement ? Modifier l'instance du singleton selon un/plusieurs paramètres d'appels lors du get_instance ?

[gege2061]

Je ne comprends pas trop ce que tu cherches à faire exactement ? Modifier l'instance du singleton selon un/plusieurs paramètres d'appels lors du get_instance ?

Je voulais éviter les aspects technique mais je pense qu'avec un exemple concret ça sera plus simple

Je créé un widget pour encapsider une fenêtre SDL (bibliothèque pour créer des jeux vidéo). On ne peux créer qu'une fenêtre, donc j'utilise naturellement un singleton.

Pour créer la fenêtre, il faut préciser sa taille, le nombre de bit par pixel, ... Seulement une fois la fenêtre crée il n'est plus possible de les modifier (ça viens pas de moi, c'est une limitation de la SDL).

Donc pour un premier appel, il faut utiliser :

Code :

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

get_instance (680, 480, 32);

Et ensuite, uniquement :

Code :

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

get_instance ();

C'est plus clair ?

[Anthony.Desvernois]

Ok ... Techniquement, je pense que tu pourrais créer des champs qui te permettent de verifier la taille de ton instance, et si les paramètres d'appels sont différents, appeler la méthode de SDL permettant de resizer la fenêtre (si existante) ou alors delete et recrée la fenêtre au bonne dimension. En gros un test quoi

[gege2061]

appeler la méthode de SDL permettant de resizer la fenêtre (si existante)

Ah si en fait c'est possible (je chercher pas au bon endroit), je vais donc utiliser une méthode avec des paramètres par défauts et mettre à jour l'affichage en cas de besoin.

[millie]

Un truc comme ça, ça suffit pas ?

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class MaClasse {
  protected MaClasse(Parametre a) {
  }
 
  static private MaClasse instance = null;
  static public getInstance() {
    if(instance==null) throw new IllegalArgumentException("");
    return instance;
  }
  static public getInstance(Parametre a) {
   instance=null;
   instance = new MaClasse(a);
   return getInstance();
  }

A changer suivant le comportement que tu veux avoir avec getInstance(Parametre)

[djo.mos]

Salut,

Un truc comme ça, ça suffit pas ?

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
 
:
:
  static public getInstance(Parametre a) {
   instance=null;
   instance = new MaClasse(a);
   return getInstance();
  }
 
:
:

Oui, mais le hic, c'est que ce n'est plus un singleton là : Si un objet a déjà récupére le getInstance, le fait qu'un autre objet l'appelle va rendre la première réference invalide (null) et retourner une nouvelle, ce qui casse le singleton.

Sinon, comme la taille de la fenêtre est changeable à souhait, ça n'a plus aucun sens de faire que getInstance prenne des paramètres. Il suffit qu'elle retourne l'unique instance de la fenêtre, qui peut exposer une méthode pour le redimensionnement.

[Luc Hermitte]

Bon. On va faire court.
Tu as besoin d'une variable globale. Tu veux un minimum de sécurité.
Donc, pas besoin de sortir la construction paresseuse, elle ne te sert strictement à rien [1]. Sans parler des problèmes inhérents à cette construction en environnement multithréadé.

Donc, un code (C++) qui répond à tes problèmes est le suivant :

Code c++ :

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
43
struct Type : private boost::noncopyable
{
    /** Accesseur au singleton.
     * @pre ms_instance != 0
     * @throw None
     */
    static Type& instance() { // à découper .h/.cpp évidemment
        assert(ms_instance && "Singleton Type non initialisé!");
        return *ms_instance;
    }
    /** Construction du singleton.
     * @pre ms_instance == 0
     * @post ms_instance != 0
     * @throw TypeException si la globale ne peut être construite
     */
    static void create(paramètres ...) {
        assert(!ms_instance && "Singleton Type déjà initialisé!");
        ms_instance = new Type(paramètres...);
    }
 
    /** Destruction du singleton.
     * @pre ms_instance != 0
     * @post ms_instance == 0
     * @throw None
     */
    void release() {
        assert(ms_instance && "Singleton Type non initialisé!");
        delete ms_instance;
        ms_instance = 0;
    }
 
 
    // + fonctions de l'interface publique de la globale
 
private:
    Type(paramètres...) { ...}
    ~Type() { ...}
 
    static Type * ms_instance;
};
 
// dans un et un seul .cpp uniquement
Type* Type::ms_instance = 0;

NB: je l'avais généré automatiquement avec un fichier template (de ma composition) pour vim.

Edit:
[1] Car c'est te mentir que de croire qu'elle puisse t'être utile si tu as besoin d'initialiser, de façon précise et non déterminée à la compilation, ton objet.

[millie]

Salut,


Oui, mais le hic, c'est que ce n'est plus un singleton là : Si un objet a déjà récupére le getInstance, le fait qu'un autre objet l'appelle va rendre la première réference invalide (null) et retourner une nouvelle, ce qui casse le singleton.

C'est pour ça que j'ai dit qu'il fallait éventuellement adapter suivant le besoin que l'on a avec la méthode getInstance(Parametre) qui ne devrait logiquement être appelé qu'une seule fois (sinon, cela n'a pas forcement de sens).

[roudoudouduo]

Je ne cache pas mon opposition complète au pattern singleton.

Toutefois en regardant de plus pres le code, le singleton abrite une classe immuable (ce qui parait être un minimum dans l'utilistion de ce pattern), et celle-ci est reinstanciée plusieurs fois au cours de la vie de l'application.

Je pense tout simplement qu'il ne s'agit pas d'un pattern singleton, et que l'usage de celui-ci n'est vraiment pas approprié (encore moins qu'accoutumée).

Eventuellement on pourrait passer par un pattern factory si besoin était :
- une méthode createInstance() qui crée une instance avec des paramètres par défauts ;
- une méthode createInstance(Parameteres) qui crée une instance avec les paramètres attribuées.

Le problème de l'unicité de l'instance ne doit pas être gérée au niveau du singleton, mais au niveau de l'objet utilisateur (celui qui apelle un singleton), à travers une simple composition.

Si l'information doit être connues par plusieurs objets et qu'à priori il n'y a aucun lien entre eux cela signifie qu'il y'a une erreur de conception (il manque par exemple un objet capable de distribuer l'information).

[vandamme]

Bon. On va faire court.
Tu as besoin d'une variable globale. Tu veux un minimum de sécurité.
Donc, pas besoin de sortir la construction paresseuse, elle ne te sert strictement à rien [1]. Sans parler des problèmes inhérents à cette construction en environnement multithréadé.

Donc, un code (C++) qui répond à tes problèmes est le suivant :

Code c++ :

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
43
struct Type : private boost::noncopyable
{
    /** Accesseur au singleton.
     * @pre ms_instance != 0
     * @throw None
     */
    static Type& instance() { // à découper .h/.cpp évidemment
        assert(ms_instance && "Singleton Type non initialisé!");
        return *ms_instance;
    }
    /** Construction du singleton.
     * @pre ms_instance == 0
     * @post ms_instance != 0
     * @throw TypeException si la globale ne peut être construite
     */
    static void create(paramètres ...) {
        assert(!ms_instance && "Singleton Type déjà initialisé!");
        return ms_instance = new Type(paramètres...);
    }
 
    /** Destruction du singleton.
     * @pre ms_instance != 0
     * @post ms_instance == 0
     * @throw None
     */
    void release() {
        assert(ms_instance && "Singleton Type non initialisé!");
        delete ms_instance;
        ms_instance = 0;
    }
 
 
    // + fonctions de l'interface publique de la globale
 
private:
    Type(paramètres...) { ...}
    ~Type() { ...}
 
    static Type * ms_instance;
};
 
// dans un et un seul .cpp uniquement
Type* Type::ms_instance = 0;

NB: je l'avais généré automatiquement avec un fichier template (de ma composition) pour vim.

Edit:
[1] Car c'est te mentir que de croire qu'elle puisse t'être utile si tu as besoin d'initialiser, de façon précise et non déterminée à la compilation, ton objet.

La methode create() ne doit - elle pas etre synchonisee en environnement multithreade ?

[Luc Hermitte]

Du tout.
Comment peut-on créer le singleton, avec paramètres, depuis plusieurs threads à la fois ?
Je n'y vois ni intérêt ni sens.

La création a lieu une seule fois avant que les divers threads de l'application ne soient démarrés.

EDIT: Avec cette forme de singleton, j'écarte la construction paresseuse au profit d'une construction avec paramètres. Ce qui est parfait pour les variables globales métiers que l'on est sensés maitriser, et que l'on désire un minimum blinder (c'est toujours mieux qu'un pointeur global que l'on pourrait oublier de "construire" depuis le main())

[hegros]

Quelque chose d'étonnant dans le code de Luc est le return dans create alors que la signature on a pour valeur de retour void.

un peu plus long et plus naif (surement pas parfaitement adapté), surtout que j'imagine que tu utilises le langage c++ avec sdl et que le code qui suit est en java..

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
public class FenetreSDL 
{
	 private FenetreSDL(int pH, int pW, int pB) 
	  {		
		 h=pH;
		 w=pW;
		 b=pB;
	  }
	 
	  public static FenetreSDL getInstance(int h,int w,int b)
	   {
	       if(_instance == null)
	         return create(h,w,b);
	       else
	         return getInstance();
	   }
	  
	   public static FenetreSDL getInstance()
	   {	      
	       return _instance;	      	    	  
	   }
	   
	   private static FenetreSDL create(int h,int w, int b)
	   {
	      _instance= new FenetreSDL(h,w,b);	       
	       return _instance;
	   }
	   
	   public static void Terminate()
	   {
		  //appel spécifique libération sdl
	     _instance = null; h=w=b=0;
	   }
	   private static FenetreSDL _instance = null;	 
	   private static int h,w,b;
}

[vandamme]

Oui, venant de sa part, je pense que ce ne peut etre qu'une etourderie ...

[Luc Hermitte]

C'est en effet une étourderie. Merci.

Sinon, le getInstance à paramètres est de trop. Il y a déjà un create() qui est sémantiquement bien plus fort -- mais on retomberait alors sur mon code ^^'

[hegros]

oui c'est pour proposer un code différemment de ce qui est déjà proposé que je suis intervenu

Je me suis plus inspiré de l'utilisation voulue donné comme exemple dans le premier post (le getInstance avec paramètre est déja de trop ^^) et en donnant un nom plus 'sémantique' aussi à la classe.