Discussion :

[sadem]

Bonjour à tous,

Dans le but de pouvoir contrôler les instances de mon formulaire, j'aimerais utiliser la classe Singleton pour l'unicité de mes formulaire à l'affichage. j'ai trouvé cette classe sur le net:

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
 
 
public sealed class Singleton
{
    static readonly Singleton instance=new Singleton();
 
    // Explicit static constructor to tell C# compiler
    // not to mark type as beforefieldinit
    static Singleton()
    {
    }
 
    Singleton()
    {
    }
 
    public static Singleton Instance
    {
        get
        {
            return instance;
        }
    }
}

Mais je me demande si mes formulaires doivent hériter de cette classe ?
Si quelqu'un peut me guider ou me donner un exemple ça m'aidera.

Merci D'avance

[antoine.debyser]

Bonjour,

Tu ne peux pas hériter de cette classe car elle est marqué "sealed", de plus héritage et statique ne font pas bon ménage dans ce cas.
Car le membre statique est censé représenter une référence partagé entre toutes les instances de ta classe et ceci inclus les instances des classes dérivées.

De là tu as deux possibilités, copier/coller ceci dans tous tes formulaires, ou créer une sorte de singleton générique que tu pourra réutiliser à souhait.

[BenoitM]

Peut-être regarder du coté du pattern Factory

[sadem]

Antoine.debyser pour le modèle générique as tu un exemple ? Pour le pattern Factory je vais faire des recherches pour voir .
Merci

[tomlev]

Mais je me demande si mes formulaires doivent hériter de cette classe ?

Non, c'est un "modèle" à suivre pour les singletons. Il faut que tu crées ta propre classe selon le même modèle (remplace "Singleton" par le nom de ta classe, et ajoute les membres que tu veux)

Peut-être regarder du coté du pattern Factory

Bah je vois pas trop le rapport avec la question... Il demande comment faire un Singleton, pas une Factory

[sadem]

D'accord je vais essayer de ce pas .Merci

[antoine.debyser]

Un exemple qui plaiera peut etre pas à tous le monde mais il marche

Code :

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

1
2
3
4
5
6
7
8
9
10
 
    public sealed class Singleton<T> where T : new()
    {
        private static readonly T _instance = new T();
 
        public static T Instance
        {
            get { return _instance; }
        }
    }

Et après si tu as une classe "Toto" que tu veux utiliser en tant que singleton

Code :

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

Singleton<Toto>.Instance.MethodeTataDeLaClassToto()

[tomlev]

Un exemple qui plaiera peut etre pas à tous le monde mais il marche

Ouais, mais ça pose un problème : tu es obligé d'avoir un constructeur public, ce qui est un peu contre nature pour un singleton...

Il y a un truc comme ça dans la lib Dvp.NET, mais ça utilise Activator.CreateInstance pour créer l'instance de l'objet à l'aide du constructeur privé. On pourrait croire que c'est plus lent, mais en fait la contrainte new() utilise aussi Activator.CreateInstance, donc a priori ça change rien. Par contre, l'inconvénient est que ça ne fonctionne que pour du code qui s'exécute en Full Trust (mais c'est généralement le cas pour une appli Windows Forms)

[antoine.debyser]

tu es obligé d'avoir un constructeur public, ce qui est un peu contre nature pour un singleton..

C'est effectivement pour ça que je dis que ça peut ne pas plaire.
Mais en même temps je me suis toujours dit que j'avais pas le choix, si je voulais pas me taper du copier/coller.
C'est plus un débat philosophique qu'autre chose, est-ce aux développeurs qui vont utiliser cette classe de faire attention à ne pas appeler le constructeur, ou est-ce à moi de verrouiller l'appel au constructeur?

Il y a un truc comme ça dans la lib Dvp.NET, mais ça utilise Activator.CreateInstance pour créer l'instance de l'objet à l'aide du constructeur privé. On pourrait croire que c'est plus lent, mais en fait la contrainte new() utilise aussi Activator.CreateInstance, donc a priori ça change rien

Du coup j'ai un peu regarder ce qui se passe coté C# désassemblé et IL.
Et là c'est assez marrant, la contraintre ne semble pas se traduire (je n'arrive pas à la retrouver dans l'IL), et l'initialisation du champs se fait en deux parties

Code :

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

1
2
3
4
5
6
7
8
9
10
11
	public class Singleton<T> where T : new()
	{
		private static readonly T _instance = (default(T) == null) ? Activator.CreateInstance<T>() : default(T);
		public static T Instance
		{
			get
			{
				return Singleton<T>._instance;
			}
		}
	}

Ce qui m'a d'ailleur appris une chose "default(T)" doit visiblement retourner null si le constructeur par défaut est privé.

Mais je suis pas sur que "Activator.CreateInstance<T>()" soit aussi rapide que "default(T)", en revanche dans notre cas on s'en tape un poil que ca soit rapide ou non la premier fois.

[tomlev]

est-ce aux développeurs qui vont utiliser cette classe de faire attention à ne pas appeler le constructeur, ou est-ce à moi de verrouiller l'appel au constructeur?

En principe une classe singleton ne peut pas être instanciée depuis l'extérieur de la classe, sinon il n'y a aucune garantie qu'on ne créera pas une autre instance. Bon, évidemment, après on peut toujours tricher en créant une instance par réflexion ou avec Activator.CreateInstance

Et là c'est assez marrant, la contraintre ne semble pas se traduire (je n'arrive pas à la retrouver dans l'IL)

Bah justement, y a pas d'équivalent IL, c'est bien pour ça qu'il utilise Activator.CreateInstance...

As far as I'm aware, there's no IL to give support for the new() constraint. Instead, the compiler emits a call to Activator.CreateInstance<T>.

Ce qui m'a d'ailleur appris une chose "default(T)" doit visiblement retourner null si le constructeur par défaut est privé.

Euh, je vois pas le rapport en fait
Le test sur default(T) sert à vérifier si T est un type référence (auquel cas ça renvoie null) ou un type valeur (dans ce cas ça renvoie une instance de la structure avec tous les champs initialisés à leur valeur par défaut). Activator.CreateInstance n'est donc utilisé que si T est un type référence, vu que pour un type valeur il est plus simple et plus rapide de faire simplement default(T)

Mais je suis pas sur que "Activator.CreateInstance<T>()" soit aussi rapide que "default(T)", en revanche dans notre cas on s'en tape un poil que ca soit rapide ou non la premier fois.

Ah bah c'est sûr que c'est beaucoup plus lent... mais vu que pour un type référence, default(T) renvoie null, ça nous aide pas beaucoup.

[sadem]

Ça marche mais une fois mon formulaire fermé il n'est plus possible de l'ouvrir.Ca me ramène cette erreur:

Cannot access a disposed object.
Object name: 'RolesList'.

Dois je testé si le formulaire a été déchargé avant l'affichage ?

Merci

[tomlev]

Une fois fermé, un formulaire ne peut plus être affiché... il faut le recréer. Donc en fait c'est pas une très bonne idée d'utiliser un singleton pour ça, sauf si c'est des forms que tu fermes jamais (éventuellement tu peux les cacher au lieu de les fermer)

[sadem]

Merci Tomlev c'est ce que je me suis dit aussi.Je vais essayer une autre solution je vous tiens informé.Ce sont des formulaires que je veux afficher dans un TabControl (Par Onglets).

[antoine.debyser]

Euh, je vois pas le rapport en fait
Le test sur default(T) sert à vérifier si T est un type référence (auquel cas ça renvoie null) ou un type valeur (dans ce cas ça renvoie une instance de la structure avec tous les champs initialisés à leur valeur par défaut). Activator.CreateInstance n'est donc utilisé que si T est un type référence, vu que pour un type valeur il est plus simple et plus rapide de faire simplement default(T)

Euh oui, fatigué moi

[sadem]

Le but que je recherche est de pouvoir afficher mes formulaires dans des onglets.Une fois, le formulaire déjà ouvert lorsqu'on clique,il doit être activé automatiquement et avoir le focus.Si c'est le cas contraire,le formulaire est créé et affiché.

Merci