Discussion :

[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

[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

[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.

[bruno_pages]

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

[hed62]

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

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

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

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
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 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
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.

[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

[hed62]

ok

[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.

[piloupy]

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

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

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

piloupy

[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.

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

[bruno_pages]

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

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

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 ?

[wiztricks]

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

[bruno_pages]

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

certe, et alors ?

[wiztricks]

certe, et alors ?

Si nous reprenons la question initiale:

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

[Hephaistos007]

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.

[piloupy]

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

Je viens de rentrer de vacances...

piloupy