Classe static ou Design Pattern Singleton ?

Version imprimable

03/07/2008, 11h20
piloupy

Classe static ou Design Pattern Singleton ?

Bonjour,

Quelle différence faites-vous entre une classe static et un singleton ?

Les 2 jouent le rôle de n'avoir qu'une seule instance de classe, donc je ne vois pas vraiment l'utilité d'un Design Pattern singleton...

Merci d'avance pour vos réponses,

piloupy
03/07/2008, 12h48
bruno_pages

une classe n'ayant que des membres statiques est un namespace déguisé et n'a donc pas besoin d'être instanciée, contrairement au singleton

j'avoue être peu fan des singletons, comme je suis fainéant devoir écrire ClasseXX::instance()->oper(...) à la place de ClasseXX::oper(...) m'insupporte, sans parler du fait que le code passera son temps à atteindre l'instance pour rien avec en prime une éventuelle protection vis à vis du multi-tâche

il reste cependant des cas ou le singleton et préférable, par exemple pour bénéficier d'héritage, et pour d'éventuels problèmes d'ordre d'initialisations au lancement de l'application
03/07/2008, 13h42
hed62

Le grand intérêt de singleton est effectivement d'assurer l'existance d'une instance (donc dont l'initialisation a été faite) d'un objet. Cela permet de ne faire cette initialisation qu'une fois, au contraire de membres statics.
03/07/2008, 17h43
bruno_pages

Citation:

Envoyé par hed62

Cela permet de ne faire cette initialisation qu'une fois, au contraire de membres statics.

je ne comprends pas en quoi il y a une différence avec les membres statiques

Les membres statiques d'un classe (statique elle aussi) ne bénéficie pas du traitement qui aurait pu préalablement être fait lors de la construction du singleton.

Je m'explique par un exemple, pas forcément bien choisi, mais bon :

Code:

1
2
3
4
5
6
7
8
9
10
 
public static class MaStatique
{
  public static object MonOperation()
  {
     //Connection à la base
     //Requete
     //retour
  }
}

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
 
 
 
public class MonSingleton {
   private MonSingletonInstance = null;
 
  Connection connectionALaBase;
 
   public static MonSingleton GetSingleton()
   {
       if (MonSingletonInstance = null)
          MonSingletonInstance = new MonSingleton();
       return MonSingletonInstance ;
    }
 
  private MonSingleton()
  {
     // connection à la base
  }
 
  public object MonOperation()
  {
     //Requete
     //retour
  }
}

Dans mon exemple, j'ai mélangé les static avec le singleton... :? On peut extraire tout ce qui est statique dans une Fabrique :

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
 
// dans un namespace
 
public class FabriqueSingleton
{
   private MonSingletonInstance = null;   public MonSingleton GetSingleton()
   {
       if (MonSingletonInstance = null)
          MonSingletonInstance = new MonSingleton();
       return MonSingletonInstance ;
    }
 
}
 
public class MonSingleton {
 
  Connection connectionALaBase;
 
  protected MonSingleton()
  {
     // connection à la base
  }
 
  public object MonOperation()
  {
     //Requete
     //retour
  }
}

La connection à la base est faite une fois pour toute.

04/07/2008, 09h25
bruno_pages

mais tu peux faire très exactement la même chose sans singleton via l'initialisation d'un des membres statiques

par contre, comme je l'avais dit, on peut alors avoir des problèmes d'ordre d'exécution car on ne domine pas l'ordre des initialisations des membres statiques/var globales

bien évidement il est toujours possible au pire de faire une fonction d'init appelée par le main

le choix entre classe avec membres statiques et singleton est une question de gout. Dans Bouml je n'est pas de singleton mais des classes avec membres statiques pour la raison évoquée dans ma première réponse
04/07/2008, 12h07
hed62

ok
05/07/2008, 10h37
el muchacho

Moi, j'ai pu constater sur un exemple professionnel que les classes comportant des membres static ont tendance a proliferer dans le code, parce que bien entendu, le compilo n'accepte pas d'instancier des classes statiques. Donc quand ta methode appelle des methodes static de divers objets, in fine ta methode est constitue d'appels de methodes static, et tu es pratiquement oblige de la rendre static. Si le code est purement du fonctionnel, c'est moyennement genant, mais ca limite serieusement les possibilites de refactoring.
Bref, l'appli que j'ai recuperee, qui est constituee en majorite de fonctions static, n'est tout simplement pas du tout objet, c'est juste une accumulation de namespaces qui s'appellent les uns les autres.
Cette proliferation des static, qui "gangrene" peu a peu les applis, je ne suis pas le seul a la constater.
Donc perso je dis mefiance: si le domaine fonctionnel des classes static n'est pas soigneusement circoncis, notamment au niveau des dependances, on en vient tres rapidement a mettre du static partout, et le code est de moins en moins objet. C'est souvent ce qui arrive avec des developpeurs debutants qui cherchent plus a satisfaire le compilateur au plus vite qu'a reflechir sur les impacts des choix architecturaux.

Merci à tous pour vos interventions enrichissantes dans ma question. J'avoue que l'échange des idées, des goûts et des points de vue de chacun m'a permi de prolonger ma compréhension entre ces 2... euh... technologies.

D'après ce que je vois, le singleton a l'air légèrement préférable (bien que cela dépende des cas), pour effectivement avoir la garantie de l'initialisation des valeurs. Pour contourner le problème de toujours faire devoir préfixer son instance, on peut le mettre dans une variable :

(au niveau du code, c'est du n'importe quoi, j'ai mélangé du Java et du C#)
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 public class MonSingleton { private MonSingleton _instance = null; private Object _synchRoot = new Object(); protected MonSingleton() { // Constructor } public static MonSingleton GetInstance() { lock (_synchRoot) { if (_instance == null) _instance = new MonSingleton(); return _instance; } } public void CreateSession() { // Code... } }
A l'usage :
Code:

1 2 3 4 5 MonSingleton instance = MonSingleton.GetInstance(); instance.CreateSession(); // etc...
piloupy

11/07/2008, 20h39
wiztricks

concept et réalisation sont des activités différentes.

Il faut faire la différence entre le pattern "singleton" qui force à un représentant/instance unique de quelque chose de sa réalisation.

L'objet de la réalisation est son intégrité vis à vis des specs, ie. qu'on n'implémente pas un machin qui n'ait pas la spécificité d'un singleton.
- W
12/07/2008, 09h51
bruno_pages

Citation:

Envoyé par piloupy

Pour contourner le problème de toujours faire devoir préfixer son instance, on peut le mettre dans une variable

je ne comprends pas trop ce que tu veux dire par là
mais de toute façon il faut obligatoirement le mémoriser dans une variable statique sinon getInstance (que j'appellerais plutôt instance tout court car il ne peut y avoir de set) ne pourra pas rendre la même instance lors des différents appels

Citation:

Envoyé par wiztricks

Il faut faire la différence entre le pattern "singleton" qui force à un représentant/instance unique de quelque chose de sa réalisation.

8O j'ai rien compris, tu sembles dire il faut faire la différence entre le pattern et sa réalisation, qu'est-ce que tu veux dire ?
12/07/2008, 10h34
wiztricks

Citation:

Envoyé par bruno_pages

8O j'ai rien compris, tu sembles dire il faut faire la différence entre le pattern et sa réalisation, qu'est-ce que tu veux dire ?

Qu'il y a plusieurs façon de "coder" la chose.
- W
12/07/2008, 11h27
bruno_pages

Citation:

Envoyé par wiztricks

Qu'il y a plusieurs façon de "coder" la chose.
- W

certe, et alors ?
12/07/2008, 13h49
wiztricks

Citation:

Envoyé par bruno_pages

certe, et alors ?

Si nous reprenons la question initiale:

Citation:

Quelle différence faites-vous entre une classe static et un singleton ?

Les 2 jouent le rôle de n'avoir qu'une seule instance de classe, donc je ne vois pas vraiment l'utilité d'un Design Pattern singleton...

Le pattern singleton permet de forcer une relation "many-to-one".
Il y a de la variabilité pour implémenter çà, qui dépend du contexte, du langage, des attributs,...

Si le concept doit se retrouver dans l'implémentation, la validité d'une implémentation repose sur d'autres critères que ceux du concept.

Sans faire cette différence, le choix d'implémentation devient une question de goût du codeur alors que ce ne devrait pas l'être (ie, il doit y avoir des raisons valables pour motiver le choix de...)

- W
18/07/2008, 19h17
Hephaistos007

Citation:

Envoyé par piloupy

Bonjour,

Quelle différence faites-vous entre une classe static et un singleton ?

Les 2 jouent le rôle de n'avoir qu'une seule instance de classe, donc je ne vois pas vraiment l'utilité d'un Design Pattern singleton...

Merci d'avance pour vos réponses,

piloupy

A première vue, on peut faire avec une classe statique ce que l'on peut faire avec une classe normale + pattern singleton. Seulement, la première solution ignore totalement le mécanisme d'instantiation, alors que la seconde non. En d'autres termes, la première solution ne permet pas de manipuler un objet, tandis que la seconde oui. Or, toute la doctrine objet est basé sur le traitement d'objets.

Considérons la classe Customer possédant trois champs nom, prénom et email, plus les selecteurs et mutateurs habituels. Considérons également la classe CustomerUtil qui offre la méthode boolean validate(Customer toBeValidated) afin de valider que le contenu des champs est bien formé. Dans un contexte particulier, on peut exiger l'existence que d'un seul customer dans le système. Si vous introduisez un pattern singleton, rien ne change, vous pouvez toujours utiliser la méthode boolean validate(Customer toBeValidated). Si vous transformez Customer en classe statique, exit la notion d'objet, et toute votre conception est à revoir.

Ce que je veux dire simplement sur cet exemple, c'est que vouloir controller l'instantiation n'a que peu d'impact sur l'existant, alors que l'utilisation de classe statique va bouleverser l'existant. Ce critère suffit à faire son choix.
01/08/2008, 16h04
piloupy

Merci encore une fois pour toutes vos interventions. Elles ont été très enrichissantes.

Je viens de rentrer de vacances... :king:

piloupy