IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Implémentation du Pattern Singleton en C#
Un article de Jon Skeet traduit par Jérôme Lambert

Le , par Jérôme Lambert

52PARTAGES

2  0 
Cette discussion est destinée à recueillir vos commentaires sur l'article Implémentation du Pattern Singleton en C# (traduction de l'article Implementing the Singleton Pattern in C# de Jon Skeet)

Le pattern singleton est un des patterns les plus connus dans le génie logiciel. Fondamentalement, un singleton est une classe qui permet une seule instance d'elle-même, et habituellement donne un accès simple à cette instance. Le plus souvent, des singletons n'autorisent aucun paramètre lors de la création de l'instance - dans le cas contraire d'une seconde demande pour une instance mais avec un paramètre différent, cela pourrait s'avérer problématique ! (Si la même instance devait être accédée par toutes les demandes avec le même paramètre, le pattern factory est plus approprié.) Cet article traite seulement le cas où aucun paramètre n'est requis. Typiquement, un critère des singletons est qu'ils sont créés en différé - c'est-à-dire que l'instance n'est créée que lors de la première fois où on en a besoin.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de olibara
Membre émérite https://www.developpez.com
Le 03/04/2012 à 7:35
Bonjour

Personnellement je prefere largement l'usage d'un singleton a celui d'une classe statique.

Il a tous les avantages d'une classe statique sans les inconvénient

J'use et abuse de la version 2 sans aucun souci
0  0 
Avatar de Reward
Membre confirmé https://www.developpez.com
Le 04/04/2012 à 9:52
J'utilise également la solution deux. Je connaissais la méthode du double check, mais certaines contreverses en faisant un antipattern (http://fr.wikipedia.org/wiki/Double-...hecked_locking) , je ne l'ai jamais mis en pratique en C#, la solution deux me convenant très bien.

Je l'ai notamment utilisé sur une couche business très sollicitée par des webservices pour améliorer les temps d'accès et réduire l'effet goulot d'étranglement dû à l'appel de plusieurs webservices sur un même manager.
0  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 04/04/2012 à 10:04
La version 2 a le mérite d'être simple et thread-safe, mais en termes de performances c'est pas génial, vu qu'il y a un lock à chaque fois qu'on veut accéder à l'instance. J'ai une préférence pour la version 4, qui est thread-safe sans avoir besoin de lock (et la version 5 s'il est important que l'implémentation soit différée).
0  0 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 04/04/2012 à 10:33
Bonjour. Contrairement à ce que l'article laissait entendre, le contenu est en fait intéressant. Par contre je trouve les considérations sur les performances totalement inutiles : dans le double-checked lock par exemple, le verrou va être exécuté une ou deux fois par type et par application. Même dans les cas les plus extrêmes (milliers de types) on resterait en-dessous d'une milliseconde au démarrage de l'appli. A mon sens c'est enseigner de mauvaises habitudes. Mais c'est là une tare de l'article original et non de la traduction. Concernant cette dernière, ma lecture n'a pas été assez attentive mais je n'ai pas relevé de coquille et le style est fluide et la ponctuation bien utilisée.
0  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 04/04/2012 à 10:47
Citation Envoyé par DonQuiche Voir le message
Par contre je trouve les considérations sur les performances totalement inutiles : dans le double-checked lock par exemple, le verrou va être exécuté une ou deux fois par type et par application.
Il ne parle pas de problème de perf pour le double-checked lock... au contraire, c'est une solution au problème de perf du lock simple. Mais de toutes façons, cette approche est un peu risquée à mon avis, on a vite fait de se planter en l'implémentant...
0  0 
Avatar de Nathanael Marchand
Rédacteur https://www.developpez.com
Le 04/04/2012 à 11:20
J'utilise toujours le Lazy<T> comme ca, c'est Microsoft que je blâme si le singleton ne marche pas
0  0