Discussion :

[ame_12]

Bonjour,

Je suis entrain de développer une classe singleton qui hérite d'une autre classe qui n'est pas singleton.
Est-ce que vous pouvez me dire si cette architecture est utilisé souvent et ne présente pas de problème particulier ?
Ou il faudrait que les deux classes soit des singletons ?

Voici un exemple de ce j'ai fais dans mon code (Shape et Rectangle sont des exemples pour exprimer la solution que je suis entrain d'implémenter).

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
#include <iostream>
 
using namespace std;
 
// Base class
class Shape 
{
   public:
	  Shape(){}
	  ~Shape(){}
 
      void setWidth(int w)
      {
         width = w;
      }
      void setHeight(int h)
      {
         height = h;
      }
   protected:
      int width;
      int height;
};
 
// Derived class
class Rectangle: public Shape
{
    private:
        /// Constructor
        Rectangle();
        /// Destructor
        ~Rectangle();
        /// Singleton instance
        static Rectangle *m_pcInstance;
 
   public:
 
		Rectangle* Rectangle::getInstance()
		{
			if(m_pcInstance == NULL)
				m_pcInstance = new Rectangle();
			return m_pcInstance;
		}
 
		Rectangle::Rectangle()
		{
		}
 
		Rectangle::~Rectangle()
		{
		}
 
		void Rectangle::vKill()
		{
			if(m_pcInstance != NULL)
			{
				delete m_pcInstance;
				m_pcInstance = NULL;
			}
		}
 
      int getArea()
      { 
         return (width * height); 
      }
};

Merci de votre aide.

[ternel]

Non, ca ne pose pas problème.

Mais par contre, un singleton est rarement une bonne idée.
Il s'agit en effet d'une variable globale (comme toute variable statique d'une classe), qui a en général le tord d'être modifiable.

Au passage, tu as oublié de définir getArea() comme une fonction constante.

[foetus]

Mais par contre, un singleton est rarement une bonne idée.
Il s'agit en effet d'une variable globale (comme toute variable statique d'une classe), qui a en général le tord d'être modifiable.

Bof

Tu mets ton singleton dans la classe principale (ou celle la plus à même de le gérer) et ensuite tu le passes en paramètre en cas de besoin.
Cela s'appelle Dependency injection il me semble

[ternel]

Et du coup, ce n'est plus un singleton, c'est un objet ayant une instance unique.

[ame_12]

Merci pour vos réponses.
Pour l'instant je vais garder la solution du singleton si elle ne présente pas de problème.
Je regarderais aussi la "Dependency injection".

Merci,

[koala01]

Salut,

en fait, je modérerais très fort la réponse de leternel : le langage l'accepte et on peut donc dire que... cela ne pose pas de problème.

Par conte, d'un point de vue conceptuel, il en va tout autrement, car, pour qu'une relation d'héritage puisse exister, il faut que le LSP soit tout à fait respecté, et ca, dans le cas présent, c'est très loin d'être prouvé.

Et puis, comme te l'ont déjà fait remarquer mes condisciples, l'idée même d'avoir recours à un singleton est rarement une bonne idée, parce que, pour qu'elle puisse être acceptée, il faut remplir deux conditions:

1. il ne peut y avoir qu'une seule et unique instance tout au long de l'exécution et
2. (surtout) l'instance en question doit être accessible depuis partout

Si la première condition est souvent présente, il "n'est pas rare" que la présence de la deuxième condition soit le symptôme d'un mauvais découpage de ton projet qui finira, tôt ou tard, par t'embrouiller complètement à cause des dépendances qui partent dans tous les sens

[ternel]

En fait, c'était ce que je voulais dire, mais très mal
Merci Koala01 de préciser ainsi