Discussion :

[behess]

En lien avec mon topic Conception Singleton et Multithreading

Voici une implémentation théorique en C# qui reprend l'idée de mehdiing :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
 
	public class Singleton
	{
		static private Singleton _instance;
		static private bool _verrou=false;
		static private int _maxWaitingDuringTime=20000;
		static public int MaxWaitingDuringTime
		{
			get{return _maxWaitingDuringTime;}
			set{_maxWaitingDuringTime=value;}
		}
 
		static Singleton()
		{
			_instance=new Singleton();
		}
		private Singleton()
		{
 
		}
 
		public static Singleton GetInstance()
		{
			int waitingDuringTime=0;
			int baseWaitingLoop=100;
			int iLoop=0;
			while(true){
				iLoop++;
				//Console.WriteLine(Thread.CurrentThread.Name+": Waiting for Singleton");
				Thread.Sleep(baseWaitingLoop*iLoop);
				waitingDuringTime+=baseWaitingLoop*iLoop;
				lock(_instance)
				{
					if(!_verrou) break;
				}
				if(waitingDuringTime>MaxWaitingDuringTime) throw new ThreadStateException("Waiting access for "+waitingDuringTime+" ms while max allowed is "+MaxWaitingDuringTime);
			}
			lock(_instance)
			{
				_verrou=true;
			}
			return _instance;
		}
 
		public static void Release(ref Singleton p_instance)
		{
			lock(_instance)
			{
				_verrou=false;
				p_instance=null;
			}
		}
	}

Qu'en pensez-vous ?

[Philippe Vialatte]

Pour ce qui est des Singleton en C#, jettes un oeil a cet article, ca devrait peut-etre t'aider :
http://webman.developpez.com/article...rns/singleton/

Sinon, pour une discussion plus longue (mais en anglais) :
http://www.yoda.arachsys.com/csharp/singleton.html

En note de bas de page, le pattern Singleton est le plus mal utilise de tous les patterns du GoF, dans 80% des cas, il est avantageusement remplace par une Factory (mais bon, c'est mon avis a moi que j'ai...)

[behess]

Pourquoi et comment une Factory pourrait remplacer un Singleton ?

[Philippe Vialatte]

Souvent, les singleton sont utilises a mauvais escient.

Le problème, c'est qu'un singleton introduit un couplage fort entre les classes qui sont des singletons et leurs consommateurs.

Le but du singleton est normalement de limiter les acces a une ressource (par exemple, un port E/S, ou autre), dans quasiment tous les autres cas, une variable globale, une factory ou un outil dÍoC procurera le meme "service", le couplage fort en moins

Apres, tout depends de ce que tu veux faire

[behess]

ça m'intéresse ce que tu me dis là !

En fait je voulais faire ceci :

- un singleton pour faciliter l'accès à la configuration
- un singleton pour l'accès au logger
- un singleton pour centraliser/dispatcher des événements
- un singleton pour l'accès à la base

Tout un programme si je puis dire !
Dans ces cas de figures précis peux-tu me suggérer autre choses que des singletons ?

[Philippe Vialatte]

- un singleton pour faciliter l'accès à la configuration

Pourquoi ? Une factory toute bete marchera aussi bien

- un singleton pour l'accès au logger

La plupart des frameworks de log doivent deja gerer le cas

- un singleton pour centraliser/dispatcher des événements

Pourquoi un singleton ? Une queue centralisee, ca ne va pas ?

- un singleton pour l'accès à la base

Probablement une mauvaise idee...Si tu es en asp.net, ca va tout peter, si tu es en winform, ca revient au meme qu'avoir une variable globale...

...bon, je crois que tout le monde a compris que j'ai ma carte du mouvement contre la singletonite

[tomlev]

Voici une implémentation théorique en C# qui reprend l'idée de mehdiing :
[...]
Qu'en pensez-vous ?

Ca me parait beaucoup, beaucoup trop compliqué pour être fiable...

Regarde le lien indiqué par Philippe sur le site de Jon Skeet, la dernière implémentation proposée est à la fois simple et robuste. Je te la recopie ici :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public sealed class Singleton
{
    Singleton()
    {
    }
 
    public static Singleton Instance
    {
        get
        {
            return Nested.instance;
        }
    }
 
    class Nested
    {
        // Explicit static constructor to tell C# compiler
        // not to mark type as beforefieldinit
        static Nested()
        {
        }
 
        internal static readonly Singleton instance = new Singleton();
    }
}

Ca combine lazy initialization et thread safety (désolé je trouve pas de traduction française appropriée pour ces termes )

Après, le singleton n'est pas forcément la solution la plus appropriée dans ton cas, mais voilà au moins comment en faire un "fiable" (enfin je suppose, j'ai tendance à prendre les écrits de Jon Skeet pour parole d'évangile )