Implémentation du Pattern Singleton en C#, traduction de l'article de Jon Skeet

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)

Citation:

---

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.

---

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

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

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

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.

Citation:

---

Envoyé par DonQuiche

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

J'utilise toujours le Lazy<T> comme ca, c'est Microsoft que je blâme si le singleton ne marche pas :aie: