Discussion :

[Xzander]

Bonjour!

J'ai cherché sur le web la différence entre une classe statique et un singleton. Voici différents points que j'ai retenus. Certains sont discutables.

Singleton:
-Permet de passer une référence à l'objet.
-Permet la sérialisation.
-Permet le polymorphisme.
-Permet de conserver un état.
-Permet le multi-threading.
-Permet un constructeur.

Classe statique:
-Permet de conserver un état.
-Permet le multi-threading (lock sur un objet statique à l'intérieur de la classe par exemple).
-Ne permet pas de constructeur, mais une méthode d'initialisation équivalente.

Dans mon cas, j'ai une classe (je ne sais pas si elle doit être statique ou un singleton) qui ne nécessite pas le polymorphisme, ni de référence, ni de sérialisation. J'ai seulement à conserver l'état et j'aurai peut-être un peu de multi-threading.

En fait, j'ai des 3 classes qui peuvent contenir des données. Les données sont extraites à partir de trois tables d'une base de données. La classe prolématique est celle qui s'occupe d'extraire les données de la base de données et de remplir un via diverses méthodes qui rempliront certains champs et retourneront un objet de type d'une des trois classes.

L'état à conserver dans la classe problématique est seulement la connexion avec la base de données et des trucs du genre.

Je peux facilement implémenter ces deux situations: utiliser une classe statique, ou utiliser un singleton. J'ai de la difficulté à voir, conceptuellement, quelle est la meilleure solution. Ce projet sert à pratiquer les bonnes méthodes de programmation, inutile de me dire de faire l'un parce que c'est plus simple, je recherche plutôt ce qui, conceptuellement parlant, est le mieux pour ma situation. Si vous croyez qu'un autre design pattern pourrait s'appliquer, ou quoi que ce soit d'ailleurs, n'hésitez pas à me le dire!

Merci pour toute aide, ou commentaires!

[Skalp]

Il y a la réponse dans la question :

Ce projet sert à pratiquer les bonnes méthodes de programmation

= design pattern.
Les deux méthodes se ressemblent assez au niveau du code, mais le singleton est beaucoup plus élégant qu'une "simple" classe statique

J'ai vu dans un bouquin qu'il existe le pattern Etat. Peut-être conviendrait-il pour tes 3 autres classes ? Mais j'en sais pas plus, je ne suis pas encore arrivé à ce chapitre ^^

[SirJulio]

Salut,

on en avait parlé il y a quelques sur ce meme forum (le thread doit avoir le meme nom que celui-la).

La principale difference, c'est que pour une classe statique, il est moins aisé de controler la durée de vie de ces membres. De fait, si un des membres à une durée de vie plus petite que celle du programme (ce qui dans le cas d'une connexion devrait etre le cas), je m'orienterai pour ma part vers le singleton.

Apres techniquement, comme tu le dis, tu peux tout à fair faire l'un ou l'autre (je trouve ca moins elegant avec une classe statique mais bon), mais conceptuellement l'approche singleton me parait meilleure.

[ced600]

En fait singleton et classe statique sont différent conceptuellement.

Un singleton te permet de n'instancier qu'une seule fois une classe. C'est son but et rien d'autre.

La classe statique a pour but de regrouper du code qui est "générique", je veux dire par là, du code qui ne dépend pas d'une classe mais qui peut être utilisé par toutes les classes. Par exemple une classe math.

Si on prend un exemple :

1) Une classe fabriquant de voiture.

2) Renault une classe qui hérite de la classe ci-dessus.

3) Une instance de Renault -> Singleton, il ne peut y avoir qu'un seul Renault, ses méthodes ne sont pas à utiliser dans toutes les classes, et ne doivent pas être accessible par tout le monde.

4) Classe Méthode de travail industrielle. -> classe statique, ses méthodes doivent être connues de tous et peuvent être utilisé par n'importe qui.

Voila j'espère que cela répond à tes questions.

Donc singleton ou statique -> cela dépende de ton architecture.

D'ailleurs un truc marrant, si tu définis les choses autrement :

1) Une classe fabriquant de voiture.

2) Renault une instance de la classe ci-dessus. -> Ni statique, ni singleton
Il peut y avoir plusieur fabriquant de voiture, mais chaque fabriquant ne doit pas exposer ses méthodes à tout le monde

(Après il y a la réflexion pour l'espionnage industrielle )

[theMonz31]

Salut ced600

je regarde ton article... je li (li)

En gros, j'ajouterais juste que la classe Static c'est un peu pour remplacer
dans bien des gars les méthodes hors classe que l'on a en C++ ou bien
un peu le concept de module en VB....

Bref, c'est pour mettre à disposition des choses qu'on ne trouve pas vraiment
dans des classes

Cela dit, chose "marrante", microsoft, pour certaines classes, fournis soit la fonctionnalité via la classe soit via une classe statique (genre File ou FileInfo)

The Monz, Toulouse

[Keihilin]

Les deux méthodes se ressemblent assez au niveau du code, mais le singleton est beaucoup plus élégant qu'une "simple" classe statique

Malheureusement, ce n'est pas sur un concept d'élégance qu'il faut se baser pour faire un choix.
Je l'ai déjà dit dans d'autres discussions sur le même sujet, on a tendance à voir une sur-utilisation du pattern Singleton parce que c'est souvent le 1er pattern que l'on apprend et qu'il est facile à placer. Du coup, on en met partout pour pouvoir dire "t'as vu mon design comme il rulez ! j'ai des singleton plein mon code" !

L'approche "il faut utiliser Singleton plutôt qu'une classe statique parce que c'est un design pattern" est fausse !

[ced600]

+1
Les design pattern sont là pour apporter des solutions. Si l'on part dans une logique que du design pattern, on risque de très vite se limiter et de faire une mauvaise architecture.
Le design pattern est une solution pas une obligation.

Par contre n'hesitez pas à regarder sur le net les design pattern existant, certain sont vraiment bien foutu. par exemple le design pattern adaptateur est très utile lorsque certaine des interfaces du projet peuvent changer ou ne sont pas encore bien définis. (mais inutile si les interfaces sont fixés et resteront inchangés.)

je regarde ton article... je li (li)

J'adore parler, alors ce ressent sur mes postes

[Skalp]

Malheureusement, ce n'est pas sur un concept d'élégance qu'il faut se baser pour faire un choix.
Je l'ai déjà dit dans d'autres discussions sur le même sujet, on a tendance à voir une sur-utilisation du pattern Singleton parce que c'est souvent le 1er pattern que l'on apprend et qu'il est facile à placer. Du coup, on en met partout pour pouvoir dire "t'as vu mon design comme il rulez ! j'ai des singleton plein mon code" !

L'approche "il faut utiliser Singleton plutôt qu'une classe statique parce que c'est un design pattern" est fausse !

Tout ça ne nous dit pas ce qui est mieux dans le cas de Xzander...

[Keihilin]

Tout ça ne nous dit pas ce qui est mieux dans le cas de Xzander...

Certes, mais à partir de ça :

Dans mon cas, j'ai une classe (je ne sais pas si elle doit être statique ou un singleton) qui ne nécessite pas le polymorphisme, ni de référence, ni de sérialisation. J'ai seulement à conserver l'état et j'aurai peut-être un peu de multi-threading.

En fait, j'ai des 3 classes qui peuvent contenir des données. Les données sont extraites à partir de trois tables d'une base de données. La classe prolématique est celle qui s'occupe d'extraire les données de la base de données et de remplir un via diverses méthodes qui rempliront certains champs et retourneront un objet de type d'une des trois classes.

L'état à conserver dans la classe problématique est seulement la connexion avec la base de données et des trucs du genre.

C'est difficile de donner une réponse.
Si j'y suis obligé, je dirais classe statique...y a moins de risques de se tromper

[Xzander]

Bonjour à tous, d'abord, merci pour vos réponses . J'ai décidé d'opter pour un singleton. J'ai bien observé l'exemple de Microsoft concernant File et FileInfo, au moyen de .Net Reflector. Il semble qu'ils ne conservent pas d'état dans leur version statique. Les méthodes de la classe statique sont indépendantes, on peut les appeler dans n'importe quel ordre, elle ne sont pas liées. C'est le cas aussi dans la classe System.Math, et diverses autres classes statiques que j'ai trouvées. Ces classes utilisent des attributs statiques, mais c'est pour y stocker des constantes, ou des paramètres d'utilisation généraux.

Je suis d'accord avec Khellin sur le fait que l'on ne doit pas abuser des singletons. Merci theMonz31 pour l'allusion à File et FileInfo. J'ai bien aimé aussi l'exemple de ced600 avec Renault. SirJulio, effectivement, dans mon cas, d'un point de vue fonctionnel, les deux me permettent d'effectuer le travail. Skalp, j'ai regardé le design pattern d'état, il ne me convient pas, mais il est très intéressant, j'ai travaillé sur une machine à états récemment, ce design pattern m'aurait été très utile, je vais le retenir!

Bref, ce que j'ai retenu, c'est que dans mon cas, la classe statique et le singleton me permettent tous deux d'implémenter ma situation. Toutefois, si jamais un jour (???) je veux avoir deux objets pointant vers deux bases de données différentes, j'aurai déjà une bonne base en utilisant un singleton.

Merci à tous pour votre aide précieuse!

[maa]

Je ne comprends pas trop pourquoi vous dites qu'une classe statique permet de conserver un état et pas un singleton.

[Nikoui]

Je ne comprends pas trop pourquoi vous dites qu'une classe statique permet de conserver un état et pas un singleton.

Heu, personne n'a dit ça ?

[ced600]

Je crois que c'est l'inverse qui a été dit.

Une classe ne conserve pas son été "instancié" car cela n'a pas de sens en soit pour classe statique car elle sera automatiquement instancié en même temps que les types. (Si c pas clair demandais à SirJulio, il sait beaucoup de chose la dessus)

Mais par contre une classe singleton connait sont état instancié ou non, c'est la base de ce design pattern pour empêcher d'autre instanciation.

Du moins voila ce que j'ai compris en ce qui concerne "etat" dont fait référence Xzander. "etat" utilisais dans un sens différent de "état" du patron de conception état (state design pattern, mais je trouve qu'avec patron de conception on se la pette plus , et puis notre langue est jolie !!!!)

[maa]

Désolé de relancer le débat, mais j'hésite encore entre l'utilisation d'une classe static et d'un singleton pour le cas suivants :
J'ai pas mal de propriétés qui sont des résultats de requêtes linq sur des collections de ma couche business. J'aimerais pouvoir accéder à ces propriété dans plusieurs classes de mon application. J'ai commencé par les mettre dans une classe static "Globals" mais je ne peux pas faire de binding sur ces propriétés car je n'ai pas d'instance les portant. Pensez-vous que l'utilisation d'un singleton conviendrait mieux ? De manière générale, doit-on utiliser un singleton chaque fois qu'on a des objets dont on veut qu'ils soient accessibles un peu partout ? Cela permet au moins la sérialisation et le binding...
Qu'en pensez-vous ?

Merci pour vos conseils.

mathmax

[ced600]

De manière générale, doit-on utiliser un singleton chaque fois qu'on a des objets dont on veut qu'ils soient accessibles un peu partout ?

Ce n'est pas le but du singleton.
Son but est de s'assurer qu'une seule instance de la classe existe.
Rien ne t'empêches de faire une méthode initialisation, de créer tes instances, et de faire des propriétés pour avoir un get sur ces instances et de les utiliser dans les classes qui voient la classes qui à initialisé les instances.