Discussion :

[StringBuilder]

Bonjour,

Je remarque que systématiquement, lorsqu'on parle de design pattern à propos de C#, on a :
- La méthode non thread safe qui demande de la programmation
- La méthode thread safe qui demande encore plus de programmation

En revanche, pour ainsi dire jamais, on ne trouve la méthode qui ne nécessaire pas de programmation : le constructeur static.

Pourquoi cette solution (que je trouve bien plus élégante) est-elle systématiquement mise de côté ?

D'un point de vue performances, je ne vois pas de problème.

De plus, comme l'illustre mon exemple, le constructeur est appeler le plus tard possible, c'est à dire que dans l'hypothèse où on ne se sert pas du singleton, on n'exécute jamais son code, ce qui est tout de même appréciable je trouve, par rapport aux solutions habituelles... non ?

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
 
 
using System;
 
namespace TestSingleton
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Ajout de 'aaaa' au Singleton");
            Singleton.UpdateVal("aaaa");
            Console.WriteLine("Ajout de 'bbbb' au Singleton");
            Singleton.UpdateVal("bbbb");
            Console.WriteLine("Récupération de la valeur du Singleton");
            Console.WriteLine(Singleton.GetVal());
            Console.WriteLine("Appuyez sur une touche pour terminer...");
            Console.ReadKey(true);
        }
    }
 
    static class Singleton
    {
        static private string val;
 
        static Singleton()
        {
            Console.WriteLine("Valeur initiale du Singleton ?");
            val = Console.ReadLine();
        }
 
        public static string GetVal()
        {
            return val;
        }
 
        public static string UpdateVal(string v)
        {
            val = val + " " + v;
            return val;
        }
 
    }
}

Sortie :

Code :

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

1
2
3
4
5
6
7
8
 
Ajout de 'aaaa' au Singleton
Valeur initiale du Singleton ?
xxxx
Ajout de 'bbbb' au Singleton
Récupération de la valeur du Singleton
xxxx aaaa bbbb
Appuyez sur une touche pour terminer...

Cette solution est pourtant je trouve bien mieux d'un point de vue sémantique :
Là où la méthode traditionnelle nous oblige à utiliser une instance de quelque-chose de statique, la méthode ci-dessus permet d'utiliser directement des méthodes statiques, sans devoir instancier le moindre objet. Sémantiquement, on est donc en présence d'un véritable singleton, et non d'une simulation de singleton...

[tomlev]

J'ai pas trop compris ton histoire... ta méthode est mieux par rapport à quoi, au juste ? Tu as un exemple des techniques compliquées dont tu parles ?

En fait, ce que tu fais là, ce n'est pas le pattern Singleton, c'est juste une classe qui expose des membres statiques; bien que ce soit suffisant dans beaucoup de cas, il arrive qu'on ait besoin de ballader une instance d'un singleton d'une méthode à l'autre, et ce n'est pas possible avec ta technique puisqu'il n'y a pas d'instance de ta classe (vu qu'elle est statique)

[StringBuilder]

Par rapport aux "vrais" singletons :

http://fr.wikipedia.org/wiki/Singlet...nception)#C.23

Justement, l'exemple que je donne fonctionne exactement pareil que le singleton habituel, hérité du C++.

Si tu l'appelles en // depuis plusieurs classes ou/et threads, la même "instance" sera utilisée.

Il ne s'agit pas bêtement d'une classe vide exposant des méthodes statiques, mais d'un objet static : il y a bien un constructeur, dans lequel on peut faire tout ce qu'on veut, et une instance implicite est alors crée, avec laquelle on peut stocker des propriétés statiques.

Si tu regardes mon exemple basique, tu verras que :
1 - On a bien initialisé l'instance avec le constructeur (présence du xxxx au début du résultat)
2 - On a appelé plusieurs fois la méthode UpdateVal() qui a modifié l'instance (concaténation de la nouvelle valeur avec l'ancienne)
3 - Le constructeur n'a été lancé qu'au moment où on a réellement eu besoin de travailler avec le singleton (on a demandé la valeur initiale au moment où on a tenté de faire un update dessus)

[Er3van]

Tu peux très bien avoir aussi quelque chose de ce type, qui ne demande pas beaucoup de code :

Code c# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class Singleton {
    private Singleton _instance;
    public Singleton Instance {
        get {
             if (_instance == null) {
                 _instance = new Singleton() ;
             }
             return _instance;
        }
    }
 
    private Singleton() { /* Do something or not */ }
}

EDIT : Oui, tu as le comportement attendu DANS CE CAS, mais si tu as plusieurs appelants ?

[StringBuilder]

Ca marche très bien.

Cf le projet VC# 2010 en pièce jointe.

Avec le second bouton de le première form, ouvre plusieurs fenêtres Form2.

Dans chacune, tape un mot dans la textbox puis clique sur le bouton.
Tu peux t'amuser à cliquer plusieurs fois sur les boutons des différentes Form2.

Ensuite, retourne dans la form1 et clique sur refresh.

=> La même instance a bien été modifiée par toutes les fenêtres.

Et en plus c'est thread safe. Et y'a pas une ligne de programmation pour la gestion du singleton (elle est parfaitement implicite).

[tomlev]

Il ne s'agit pas bêtement d'une classe vide exposant des méthodes statiques, mais d'un objet static : il y a bien un constructeur, dans lequel on peut faire tout ce qu'on veut, et une instance implicite est alors crée, avec laquelle on peut stocker des propriétés statiques.

1 - On a bien initialisé l'instance avec le constructeur (présence du xxxx au début du résultat)

Non, aucune instance n'est crée, ni implicite ni explicite. Et même si c'était le cas, ça ne change rien au problème que je mentionnais plus haut : même si une instance implicite était effectivement crée, tu ne peux pas passer la passer en paramètre d'une méthode, par exemple, puisque tu ne peux pas y accéder

En plus, la classe étant statique avec seulement des membres statiques, elle ne peut pas implémenter une interface, ce qui limite un peu les options.

Encore une fois, je ne dis pas que cette approche n'est pas valide, elle est tout à fait adaptée dans certains cas, mais c'est différent du pattern Singleton.

3 - Le constructeur n'a été lancé qu'au moment où on a réellement eu besoin de travailler avec le singleton (on a demandé la valeur initiale au moment où on a tenté de faire un update dessus)

Dans ce cas, effectivement il n'est lancé qu'au moment où tu en as besoin. Mais vu la complexité des règles qui régissent ce comportement, j'y réfléchirais à 2 fois avant de me baser dessus (surtout qu'il arrivent qu'elles changent d'une version à l'autre du framework).

Je te conseille la lecture de cet article concernant l'implémentation d'un singleton thread-safe avec lazy initialization. Tu verras que ce n'est pas aussi simple que ça en a l'air...

Et celui là aussi pour la route (à propos de l'initialisation des types)

[tomlev]

Ca marche très bien.

Cf le projet VC# 2010 en pièce jointe.

Avec le second bouton de le première form, ouvre plusieurs fenêtres Form2.

Dans chacune, tape un mot dans la textbox puis clique sur le bouton.
Tu peux t'amuser à cliquer plusieurs fois sur les boutons des différentes Form2.

Ensuite, retourne dans la form1 et clique sur refresh.

=> La même instance a bien été modifiée par toutes les fenêtres.

Bah oui, c'est le principe des membres statiques... les données statiques sont partagées par tout l'AppDomain. Ca n'en fait pas un singleton pour autant

[Nathanael Marchand]

Allez soyons fou! Un singleton thread safe en deux lignes en .Net4

Code :

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

1
2
3
4
5
6
7
8
9
 
public class MaClasse
{
    private static readonly Lazy<MaClasse> Lazy = new Lazy<MaClasse>(()=>new MaClasse());
    public static MaClasse Instance {get {return Lazy.Value;}}
 
    private MaClasse()
    {//blabla}
}

[StringBuilder]

Je ne cherche pas la polémique, je cherche juste à m'instruire et comprendre : en effet, pour le moment je ne vois pas de différence dans l'utilisation, certainement par manque de cas concret.

Même si une instance implicite était effectivement crée, tu ne peux pas passer la passer en paramètre d'une méthode, par exemple, puisque tu ne peux pas y accéder.

Je ne comprend pas l'intérêt de passer un singleton en paramètre.
Le principe du singleton est bien d'avoir la même instance quel que soit l'endroit du code, non ? Dans ce cas, pourquoi voudrait-on le passer en paramètre, autant avoir une instance globale non ?

En plus, la classe étant statique avec seulement des membres statiques, elle ne peut pas implémenter une interface, ce qui limite un peu les options.

Dans quel cas peut-on tirer partie de ce genre de choses ? Avez-vous un exemple ?

[tomlev]

Je vais essayer de te faire un petit exemple (un peu bidon mais bon, c'est juste pour illustrer)...

Supposons que tu aies une classe statique AnimalFactory :

Code :

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

1
2
3
4
5
6
7
public static class AnimalFactory
{
    public static Animal CreateAnimal()
    {
        return new Giraffe();
    }
}

Et une méthode MakeABunchOfAnimals, qui utilise cette classe statique :

Code :

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

1
2
3
4
5
    public IEnumerable<Animal> MakeABunchOfAnimals(int count)
    {
        for (int i = 0; i < count; i++)
            yield return AnimalFactory.CreateAnimal();
    }

Le problème, c'est que tu voudrais pouvoir indiquer à la méthode le type d'animaux à créer. Alors bien sûr, tu pourrais créer plusieurs méthodes dans AnimalFactory (par exemple CreateGiraffe, CreateBear, etc), et passer à la méthode un paramètre qui lui indique quel méthode utiliser. Ce qui donnerait par exemple un truc comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
    public IEnumerable<Animal> MakeABunchOfAnimals(string kind, int count)
    {
        for (int i = 0; i < count; i++)
        {
            if (kind == "Giraffe")
                yield return AnimalFactory.CreateGiraffe();
            else if (kind == "Bear")
                yield return AnimalFactory.CreateBear();
            else if (kind == "Lion")
                yield return AnimalFactory.CreateLion();
        }
    }

(évidemment on aurait aussi pu implémenter cette logique dans AnimalFactory.CreateAnimal, mais ça ne fait que déplacer le problème)

Pas très pratique... surtout qu'à chaque fois que tu veux un nouveau type d'animal, il faut créer une nouvelle méthode dans AnimalFactory, et modifier le code de MakeABunchOfAnimals pour ajouter un cas.

En fait, ce qu'il te faudrait pour que ce soit plus pratique, c'est avoir plusieurs implémentations différentes de AnimalFactory, que tu pourrais passer en paramètre de MakeABunchOfAnimals. Mais comme ta classe AnimalFactory est statique, tu ne peux pas la passer en paramètre...

La solution est de créer une interface IAnimalFactory :

Code :

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

1
2
3
4
public interface IAnimalFactory
{
    Animal CreateAnimal();
}

Avec plusieurs classes qui implémentent cette interface, et qui peuvent éventuellement être des singletons :

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
public class GiraffeFactory : IAnimalFactory
{
    private static readonly GiraffeFactory _instance = new GiraffeFactory();
    private GiraffeFactory() { }
 
    public static GiraffeFactory Instance { get { return _instance; } }
 
    public Animal CreateAnimal() { return new Giraffe(); }
}
 
public class BearFactory : IAnimalFactory
{
    private static readonly BearFactory _instance = new BearFactory();
    private BearFactory() { }
 
    public static BearFactory Instance { get { return _instance; } }
 
    public Animal CreateAnimal() { return new Bear(); }
}

Ensuite, plus qu'à modifier MakeABunchOfAnimals pour qu'elle accepte un IAnimalFactory :

Code :

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

1
2
3
4
5
    public IEnumerable<Animal> MakeABunchOfAnimals(IAnimalFactory factory, int count)
    {
        for (int i = 0; i < count; i++)
            yield return factory.CreateAnimal();
    }

Et tu peux ensuite appeler MakeABunchOfAnimals avec la factory que tu veux, pour créer tel ou tel type d'animal :

Code :

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

1
2
var bears = MakeABunchOfAnimals(BearFactory.Instance);
var giraffes = MakeABunchOfAnimals(GiraffeFactory.Instance);

Bref... je sais que cet exemple est un peu contraint et ne correspond pas exactement à un scénario réel, mais il est simple et illustre bien le problème.

Tu remarqueras que le fait d'utiliser un singleton est ici un détail : rien n'oblige les implémentations de IAnimalFactory à être des singletons. Par contre, elles sont obligées d'êtres des classes non statiques, dont on peut manipuler une instance.

Au final, les singletons et les classes statiques ne remplissent simplement pas le même rôle, même si on peut trouver des similitudes. Dans ton exemple, si tu veux juste partager globalement dans ton application une valeur de string, une classe statique fait très bien l'affaire, mais un singleton aurait été inadapté (en tous cas il n'aurait rien apporté de plus). Faire un classe statique "à la place d'un singleton" n'a pas vraiment de sens, ou alors c'est que tu n'avais pas vraiment besoin d'un singleton à la base...

(désolé pour ce roman, je me suis un peu laché )

[StringBuilder]

Bonjour,

Ne sois pas désolé pour ce roman, au contraire, je suis très content d'avoir une réponse exhaustive.

Je dois être un peu attardé, mais je trouve ça encore un peu trop abstrait. Je comprends bien là où tu veux en venir en pointant du doigt la différence, mais je n'arrive pas à imaginer de cas concret où l'utilisation du singleton est réellement nécessaire.

Actuellement, je me sert de classes statiques pour gérer par exemple, au niveau application :
- Un fichier INI (lecture et parsing du fichier INI dans le constructeur, enregistrement dans le destructeur, et accès aux propriétés statiques en lecture/écriture dans le programme.
- Une connexion à une base de données : avec un timeout mutualisé à toute l'application (pas besoin de gérer le cas de la connexion perdue au moment de l'appel de l'objet connexion)
=> D'ailleurs, dans ce cas, j'utilise bien une interface, puisque je retourne une IConnection, et que j'instancie l'objet à grands coups de reflexion après lecture de la cnxstring.

[tomlev]

- Un fichier INI (lecture et parsing du fichier INI dans le constructeur, enregistrement dans le destructeur, et accès aux propriétés statiques en lecture/écriture dans le programme.

Et comment tu fais si tu as plusieurs fichiers INI ?

- Une connexion à une base de données : avec un timeout mutualisé à toute l'application (pas besoin de gérer le cas de la connexion perdue au moment de l'appel de l'objet connexion)

Et si tu as besoin de te connecter à plusieurs DB différentes ? Eventuellement en même temps ? Ou même plusieurs fois à la même DB sur différents threads ?

Le problème de l'approche statique est que tu finis toujours par tomber sur ce genre de limitations... même si ça peut sembler suffisant au départ, tu verras souvent que quand l'application évolue, ça ne suffit plus. Mais en l'occurrence un Singleton ne serait pas adapté non plus de toutes façons

[StringBuilder]

Hmmm, ok pour le coup des différents INI.

Pour l'appel à la bdd depuis plusieurs threads, je ne me suis effectivement jamais posé la question, puisque je ne fais que peu d’asynchrone, et que les différentes fenêtres de mes applications sont le plus souvent modales, donc effectivement, pas de traitements concurrentiels, même si c'est des threads différents.

[oyigit]

Fonctionnellement c'est très proche.

En revanche, il y a des différences dans la philosophie objet, au moins au niveau de l'évotulivité. On peut plus facilement jouer sur l'héritage (abstract, virtual). On peut ainsi modifier le comportement d'une classe de base.

Par ailleurs, on peut serialiser un singleton, chose que tu ne feras pas avec une classe statique...