Discussion :

[ecplusplus]

Bonjour,

Une pensée "philosophico-programmeuse" me traverse l'esprit depuis ce matin .

Une variable statique est une variable de classe ce qui veut dire que tous les objets de cette classe référence la même variable.

Un singleton permet de n'avoir qu'un seul objet d'une classe.

Ma question est donc : "Une variable statique a t-elle un rôle justifié dans une singleton" ?

[hegros]

oui d'ailleurs c'est toujours comme cela que je l'ai vu implémenté.

Version ultra-light

Code :

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

1
2
3
4
5
6
7
8
9
10
class Singleton
{
    static Singleton singleton = new Singleton();

   static Singleton getInstance() 
   {
         return singleton;
   }
}

[ecplusplus]

Ma question était portée bien évidemment sur les autres variables éventuelles qu'il pourrait y avoir dans la classe.

Y a-t-il un cas où une variable statique aurait un intérêt dans un singleton puisque par définition il n'y aura qu'un seul objet de cette classe ?

[hegros]

Y a-t-il un cas où une variable statique aurait un intérêt dans un singleton puisque par définition il n'y aura qu'un seul objet de cette classe ?

J'ai du mal à te suivre. Tu remarqueras que la méthode pour accéder à l'objet est statique donc tu ne peux qu'utiliser des membres statiques dedans.

Aussi il existe plusieurs variantes d'implémentation de ce pattern et de façon de l'utiliser correctement.

Cas d'école

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class Singleton
{
    static Singleton singleton = new Singleton();
    static int compteurAppel = 0;

   static Singleton getInstance() 
   {
        compteurAppel++;
         return singleton;
   }
}

[Patriarch24]

J'ai du mal à te suivre. Tu remarqueras que la méthode pour accéder à l'objet est statique donc tu ne peux qu'utiliser des membres statiques dedans.

Précision : dans la méthode getInstance oui, mais pas forcément dans les méthodes de l'instance.

[hegros]

Précision : dans la méthode getInstance oui, mais pas forcément dans les méthodes de l'instance.

Cela s'applique à toutes les méthodes statiques donc même celle de l'instance.

J'avoue ne pas trop savoir ou elle veut en venir avec cette histoire d'interet des variables statiques, on peut les utiliser pour les constantes aussi donc oui il y a un interet

[ecplusplus]

J'avoue ne pas trop savoir ou elle veut en venir...

Non non, c'est IL !

Je vais essayer d'être plus clair.

Qu'est-ce qu'un singleton ? C'est une classe qui n'aura qu'une seule instance.
Qu'est-ce qu'une variable statique ? C'est une variable qui n'est pas rattachée à l'OBJET, mais à la CLASSE !!! Donc il n'y aura qu'UNE SEULE variable statique pour tous les objets instanciés.

Ma question est donc de trouver un intérêt à mettre une variable statique dans un singleton (autre que celle qui sont là pour créer le singleton), puisque de toutes façons il ne peut y avoir qu'UN SEUL OBJET de la classe !!!

Donc maintenant est-ce que quelqu'un voit un intérêt quelconque ? Je suis intéressé par une vraie réponse et non le fait de me faire agresser.

Merci

[Farid_92]

Salut,

Dans un cas general, la reponse a ta question est non.
A part le statique de l'instance, il n'y a pas besoin de declarer d'autres variable statique.
De part la nature du singleton toutes les variables seront partagées par tous les objects accedant au singleton, le STATIQUE deviendrait donc redondant.

Le seul cas que je pourrais imaginer c'est si tu veux definir des constantes (static final) dans le singleton au lieu de les definir dans des interfaces.

Maintenant toutes les situations ne se resolvent pas de manieres unique.
Donc si tu as un cas concret montre le nous.

---
Farid.

[Hephaistos007]

J'ai du mal à comprendre où tu veux en venir.

Pour essayer d'y voir plus clair, j'ai une question pour toi : à quel autre moyen penses-tu pour implémenter un singleton ?

[behess]

Peut-être que la question sous-jacente est :

quel est l'intérêt du Singleton

par rapport à

une implémentation "tout statique" qui garanti déjà que tout ne sera présent qu'en un seul exemplaire au niveau de la classe elle-même.

Un élément de réponse, extrait du chapitre "Singleton" très bon livre "Tête la première - Design Patterns".

Question: Est-ce que je ne peux pas me contenter de créer une classe dont toutes les méthodes et les variables sont statiques ? Ne serait-ce pas identique à un Singleton ?

Réponse: Oui, si votre classe est autonome et ne dépend pas d'une initialisation complexe. Toutefois, en raison de la façon dont Java gère les initialisations statiques, cela peut donner un vrai gâchis, surtout si plusieurs classes sont impliquées. Ce scénario aboutit souvent à des bogues subtils et difficiles à détecter, qui sont liés à l'ordre des initialisations. A moins qu'il n'y ait une raison impérative d'implémenter votre "singleton" de cette façon, il est de beaucoup préférable de rester dans le monde objet.

[ecplusplus]

J'ai été un peu absent ses temps-ci donc désolé de la réponse tardive.
En tout cas je vous remercie, vous m'avez donné les réponses que je voulais.

J'ai un collègue qui avait Design Pattern de la collection Tête la première, et il avait vraiment l'air bien fait. J'ai pour ma part celui du "GOF" : "Elements of reusable object-Oriented Software" qui est malheureusement en anglais et je dois dire que je ne suis pas super à l'aise avec l'anglais.

[rp37000]

Bonjour ecplusplus,

Concernant ta question initiale:

Ben oui pourquoi pas une ou plusieurs autres static, dans une classe singleton!

Exemple: si (pour une raison ou pour une autre...) je veux compter le nombre
d'appel à la méthode getInstance() de cette classe.

Mais on pourrait me répondre : "ben dans ce cas pourquoi ne pas mettre ça DIRECTEMENT dans un membre (non static) de l'instance(unique donc)?"

Cette remarque se tient , cependant: il ne faut pas mélanger ce qui est du ressort de la classe et ce qui est du ressort des objets (ici un seul donc)
ayant pour type cette classe.
Une propriété de classe (static donc) N'EST PAS une propriété d'instance (même unique) de cette classe. C'est juste une question de principe, de rigueur et d'évolutivité. Ces 2 notions (static / non-static) existent et chacune à son rôle... (ce n'est pas pour des prunes... :o)).

D'ailleurs si un jour la classe n'est plus singleton (pour une raison ou une autre...) il faudra faire la part des choses entre propriétés de la classe elle-même et propriétés de ses instances... alors autant le faire dés maintenant pour éviter les confusions futures et les pertes de temps pour réorganiser proprement les codes clients de cette classe, si elle devient en effet un jour NON singleton.

La distinction doit être bien maintenue à mon sens... pour toutes ces raisons, au moins.

Espérant répondre à ton interrogation.

[rp37000]

Au fait , concernant le livre "DP tête la première", je l'ai lu de bout en bout,
il peut vraiment être très enrichissant, même s'il n'est pas parfait non plus.
En tout cas ça m'a éclairé et appris sur beaucoup de points.
;o)

[SKZ81]

Aussi il existe plusieurs variantes d'implémentation de ce pattern et de façon de l'utiliser correctement.

Cas d'école

Ton exemple peut très bien se coder :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class Singleton
{
    static Singleton singleton = new Singleton();
    int compteurAppel = 0;

   static Singleton getInstance() 
   {
        this->singleton.compteurAppel++;
         return singleton;
   }
}

Néanmoins c'est moins rapide (pardon, efficace).

Bon après, même si c'est pas super propre, j'ai vu des singletons qui se mexait avec des classes utilitaires : leur rôle central dans l'appli était assez logique pour qu'il référence les principaux objets et présente quelques méthodes utilitaires. Disons que la conception n'était pas super rigoureuse vis-à-vis des D.P. mais néanmoins les déveurs s'y retrouvaient.
Dans ce genre de cas, il est assez tentant de rajouter quelques attributs statiques pour assurer le fonctionnement des méthodes.

Mais la réponse stricte à ta question est non, aucun besoin, la preuve est l'exemple de code en début de post.