Singleton vs. static ?

[BastienCil]

Je me demandais pourquoi faire une class singleton si je peux tout simplement la faire avec tous mes attributs et mes méthodes static ? Ça reviendrait à la même chose non !? Le premier aurait seulement qu'une instance et le second utiliserait directement la class sans passer par une instance.

[wiztricks]

Salut,

Le singleton est un pattern de conception.
Il s'agit de rendre compte que certains objets de l'application sont uniques.
Exemple: le fichier de configuration, la connexion au SGDB,...

Réaliser "cette propriété" avec du code dépend du langage de programmation utilisé. Avec un langage OO, "instancier" servira à appeler le constructeur et initialiser l'objet (ouvrir le fichier, la connexion,...).

Si le propos est d'encapsuler des variables globales dans une classe, pas la peine d'instancier ni même d'appeler cela Singleton, "variables globales" est quand même plus juste.

- W

[thebloodyman]

Envoyé par BastienCil

Je me demandais pourquoi faire une class singleton si je peux tout simplement la faire avec tous mes attributs et mes méthodes static ? Ça reviendrait à la même chose non !? Le premier aurait seulement qu'une instance et le second utiliserait directement la class sans passer par une instance.

Bonjour,

Je me posais la même question que toi il y a quelques années.
C'est un sujet très intéressant je trouve.

Pour répondre à ta question, en apparence, oui, cela reviendrait au même, en réalité, c’est plus compliqué.


Tout dépend de ce que tu veux mettre dans ces méthodes statiques.
Si par exemple, tu veux mettre du métier et que tu souhaites réaliser des tests unitaires avec des outils standards, tu auras du mal à mocker ou stuber les appels à ces méthodes statiques puisque que cette classe n'a pas d'instance. (Il existe des apis qui modifient le bytecode pour cela mais je préfère ne pas les utiliser).
L'argument est également valable si tu souhaites modéliser des hiérarchies de classes ou d’interfaces autour de ta classe. En effet, les méthodes statiques ne peuvent pas faire partie d’une hiérarchie de type, donc une classe qui ne comporte que des méthodes statiques perd donc rapidement son utilité dans une conception POO: la méthode est ni contractualisable (interface), ni héritable, ni redéfinissable (héritage).

C'est pourquoi les classes final abstract non instantiable, qui comportent uniquement des méthodes statiques sont souvent des classes avec des méthodes utilitaires basiques, plutôt génériques, avec peu ou pas de logique métier et ne s'inscrivant pas dans une conception OO, ex : formatage de date, copy de beans, conversions, factory d’objets, etc… Ce type de classe ressemble davantage à ce que l'on fait dans les langages purement procéduraux.
Elles ont leur utilité, car comme tu l'as remarqué, elles sont simples à créer et à manipuler. Mais elles ont également leur limite, à l'instar des langages procéduraux.

Perso, je les utilise les mais j’essaye de le faire à bon escient.

[wiztricks]

Salut,

Envoyé par thebloodyman

C'est pourquoi les classes final abstract non instantiable, qui comportent uniquement des méthodes statiques sont souvent des classes avec des méthodes utilitaires basiques, plutôt génériques, avec peu ou pas de logique métier et ne s'inscrivant pas dans une conception OO, ex : formatage de date, copy de beans, conversions, factory d’objets, etc… Ce type de classe ressemble davantage à ce que l'on fait dans les langages purement procéduraux..

Tout cela est assez spécifique au monde Java... qui est fort respectable certes mais avec des contraintes que n'ont pas d'autres langages sur ce sujet.
- W

[thebloodyman]

Envoyé par wiztricks

Salut,



Tout cela est assez spécifique au monde Java... qui est fort respectable certes mais avec des contraintes que n'ont pas d'autres langages sur ce sujet.
- W

Salut wiztricks,

En C#, j'ai également eu à faire à ce type de problématique. En même temps, c'était un clone de Java à l'origine...

Tu parles de quel langage en particulier ?

[jcdentons]

Bonjour,

Il me semble qu'une autre différence est le temps d'accès et la possibilité de décharger un singleton de la mémoire. Les attributs et méthodes static doivent rester en mémoire dès lors que la classe est appelée une fois, alors que pour un singleton, si l'instance unique est passée à null (à l'aide d'une méthode static "Liberer" par exemple), ses membres ne se trouvent plus en mémoire. Par contre, à chaque fois qu'on l'instancie, il y a un temps de création de l'objet ...

Sauf si je me trompe, le singleton a ces deux particularités par rapport aux attributs et méthodes static.

[wiztricks]

Envoyé par thebloodyman

En C#, j'ai également eu à faire à ce type de problématique. En même temps, c'était un clone de Java à l'origine...

Le PO ne parle pas d'un langage particulier sinon il aurait probablement posté sa question dans le forum ad hoc.
De plus le Singleton est un pattern de conception, on le réalisera en fonction des besoins et des possibilités du langage.

- W

[wiztricks]

Envoyé par jcdentons

Il me semble qu'une autre différence est le temps d'accès et la possibilité de décharger un singleton de la mémoire. Les attributs et méthodes static doivent rester en mémoire dès lors que la classe est appelée une fois, alors que pour un singleton, si l'instance unique est passée à null (à l'aide d'une méthode static "Liberer" par exemple), ses membres ne se trouvent plus en mémoire. Par contre, à chaque fois qu'on l'instancie, il y a un temps de création de l'objet ...

Si le Singleton se réduit à des variables "globales", elles seront accessibles pendant toute la durée du programme modulo une initialisation. Si le Singleton doit exister de temps en temps pendant la durée de vie du programme, il sera plus simple "d'instancier" un objet pour le libérer en cas de besoins.

Ces fonctionnalités supplémentaires coûteront "plus".

Ceci dit, lorsqu'on code dans un langage particulier, il y a des "bonnes pratiques" côté réalisation d'un Singleton qu'il peut être judicieux de respecter: tout le monde reconnaîtra la réalisation d'un Singleton...
Cette réalisation a des fonctionnalités superflues vis à vis du Singleton de la "conception" mais on évitera des pertes de temps à assurer que la "réalisation" est fidèle aux attentes (à la "conception"),

- W