Singleton et l'héritage

Version imprimable

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:

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.

05/04/2016, 14h33
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.
05/04/2016, 14h43
foetus

Citation:

Envoyé par leternel

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 :mrgreen:

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
05/04/2016, 14h45
ternel

Et du coup, ce n'est plus un singleton, c'est un objet ayant une instance unique.
05/04/2016, 14h58
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,
06/04/2016, 21h20
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 ;)
07/04/2016, 08h04
ternel

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