application multiform : qui doit déclarer ?

Bonjour,

J'ai une application avec plusieurs form. Je me demande qui doit déclarer les instances de ces forms.
Au début, j'ai déclaré tout mes forms dans ma form principale. Puis je me suis rendu compte que j'avais parfois besoin dans certaines d'entre elles d'avoir connaissance d'autres form (pour les afficher par exemple). J'ai alors pensé les déclarer dans une classe statique de sorte que tous le monde puisse y avoir accès.
J'aimerais savoir si il existe une meilleure solution, un design-pattern pour ce genre de problème.
J'ai tendance à penser que déclarer une form dans une autre est rarement une bonne solution car c'est lier les 2 entre elles et donc peu évolutif si l'on veut par la suite que d'autre classe puisse accéder à cette form. Qu'en pensez-vous ?

Merci d'avance pour vos conseils.

mathmax

Bonsoir

Si ton problème est de n'avoir toujours qu'une seule instance de chaque Form et de limiter les dépendances tu peux essayer le pattern Fabrique avec un soupçon de cache.

En gros lorsqu'une Form doit en appeler une autre, elle fait appel à la Fabrique qui va vérifier si la nouvelle Form n'existe pas déjà avant de l'instancier et de retourner cette instance à la forme appelante. De plus l'objet retourné sera de type Form et l'appelant pourra utiliser sa méthode Show().

Evite le statique autant que possible, bien que tu puisses créer une Fabrique Singleton.

Citation:

---

J'ai tendance à penser que déclarer une form dans une autre est rarement une bonne solution car c'est lier les 2 entre elles et donc peu évolutif si l'on veut par la suite que d'autre classe puisse accéder à cette form

---

Hum ! J'ai du mal à saisir ce que tu entends par "déclarer".

En POO tu manipules des classes, et pour plus de commodité tu crées un fichier source par classe. Ces classes sont publiques, donc toutes les classes qui sont dans le même namespace, ou dans des namespaces référencés par des using, peuvent être utilisées.

Peux-tu détailler ce que tu cherches à faire ?

Bon courage

Christophe B.

Merci pour ta réponse.

Mon problème n'est pas de limiter/contrôler la fabrication de form, mais de savoir dans quelle classes ces form doivent être déclarer (autrement dit de quelle classe seront-elle membre).
Je donne un exemple pour être plus clair :
J'ai une form principale. Depuis celle-ci on peut afficher/masquer 2 nouvelles forms : form2 et form3. Si je veux pouvoir afficher/masquer ou utiliser n'importe quelle méthode de form3 dans form2, il faut que cette dernière ait connaissance de l'instance de form3. Si form3 est déclarée membre de ma form principale alors form2 n'en a pas connaissance. Voilà pourquoi je me proposait de déclarer toutes ces forms dans une classe statique de sortent qu'elles puissent "se connaître" les unes des autres.
Est-ce que mon problème est plus clair ?

Et pourquoi pas simplement obtenir (ou posséder) une référence sur tes forms.

En gros une référence de ta form2 dans form3 (alors qu'elle a été instancié dans form1 par exemple).

Le DP proposé par elbj pourrait donc te convenir.

@elbj : tu pourrais m'en dire plus sur le DP Cache (si c'est bien un DP), je ne le connais pas.

:merci:

Citation:

---

Envoyé par Skyrunner

@elbj : tu pourrais m'en dire plus sur le DP Cache (si c'est bien un DP), je ne le connais pas.

---

J'interprete ça comme un factory qui garde en mémoire les instances des fenêtres créées, et qui ne renvoie pas une nouvelle instance à chaque fois. Cela permet de ne pas ouvrir 22 fois la même fenêtre.
Mais dans ce cas-là, ce n'est plus trop un factory.

Citation:

---

Et pourquoi pas simplement obtenir (ou posséder) une référence sur tes forms.

---

Oui mais alors comment les obtenir ? Je les passes en paramètre lors de la construction de mes forms ? Ca n'est pas un pue lourd, si je me retrouve avec une dizaine de form à passer en paramètre ?

Citation:

---

Envoyé par maa

Oui mais alors comment les obtenir ? Je les passes en paramètre lors de la construction de mes forms ? Ca n'est pas un pue lourd, si je me retrouve avec une dizaine de form à passer en paramètre ?

---

Dans tous les cas tu passes juste une référence, c'est pas plus lourd que de passer un string. Une référence ça doit être 4 octets je pense.

Citation:

---

Envoyé par SaumonAgile

J'interprete ça comme un factory qui garde en mémoire les instances des fenêtres créées, et qui ne renvoie pas une nouvelle instance à chaque fois. Cela permet de ne pas ouvrir 22 fois la même fenêtre.
Mais dans ce cas-là, ce n'est plus trop un factory.

---

C'est ce que j'ai aussi pensé, mais oui ça ressemble plus trop à une Factory si du coup elle ne fabrique qu'un objet de chaque type (elle va vite faire faillite la fabrique :lol:).

Citation:

---

Dans tous les cas tu passes juste une référence, c'est pas plus lourd que de passer un string. Une référence ça doit être 4 octets je pense.

---

Je ne parlais pas en terme de performance, mais en terme de lisibilité. Est-ce bien la manière la plus propre de faire ? Pourquoi ne pas utiliser une classe statique qui contient les références à toutes les forms ? De cette façon elle sont accessibles partout sans que l'on ait besoin des les passer en paramètre à chaque fois ? Sinon, je pourrais stocker toutes ces instances dans une unique classe et je passe cette classe en paramètre à chacune de mes forms. :roll:
Je cherche la solution la plus propre, la plus évolutive, la plus lisible de faire. Comment à t-on l'habitude de faire pour ce genre de cas de figure ?

Salut Maa,

je pense, pour le dernier message qu'il n'y a pas reellement de bonne facon de faire, chacun a ses petites habitudes.

Pour ma part, j'utilise souvent une classe static (ou "singletonnée") encapsulant un Dictionary<string, Form> pour les Forms principales pouvant etre acceder de plusieurs endroits dans le code. Pour les forms exclusives (comprendre structurellement fortement attachée à une autre form, et de durée de vie courte), je les declare et utilise directement dans le parent. Certes ce n'est pas forcement un exemple de decouplage mais somme toute est-ce que le decouplage est forcement necessaire pour ce genre de relation.

A noter aussi, mieux vaut eviter de faire des constructeurs parametrés pour les forms, ca peut etre ennuyeux si un jour cette form doit servir de classe de base à une classe tierces. Mieux vaut passer par une propriété si besoin est.

Merci pour ta réponse.

Deux questions :
- si tu utilises une classe singletonnée, comment fais-tu pour pouvoir y accéder dans tes forms ? Tu dois avoir une référence à cette classe dans chacune de tes forms. Mais si tu n'instancies pas celle-ci à la construction de ta form, tu n'es jamais sûr qu'elle a bien été instanciée, non ?

- Pourquoi utilises-tu un Dictionary<string, Form> ?

Citation:

---

Envoyé par maa

Merci pour ta réponse.

Deux questions :
- si tu utilises une classe singletonnée, comment fais-tu pour pouvoir y accéder dans tes forms ? Tu dois avoir une référence à cette classe dans chacune de tes forms. Mais si tu n'instancies pas celle-ci à la construction de ta form, tu n'es jamais sûr qu'elle a bien été instanciée, non ?

---

Ben le principe du classe singletonnée c'est d'avoir toujours la même instance.

Donc tu n'as pas besoin d'avoir une référence sur la classe dans tes forms, seulement de récupérer l'instance via le GetInstance de ta classe Singleton.

Le dictionnaire c'est juste pour lier un string à une Form je pense, une clé tu associes une form pour les récupérer plus facilement.

ah oui évidemment. :oops:

Et pour l'utilité du dictionary<string, Form> ?

Citation:

---

Envoyé par maa

ah oui évidemment. :oops:

Et pour l'utilité du dictionary<string, Form> ?

---

Bah à la limite, tu peux faire ca plus barbarement, du genre :

Code:

---

1 2 3 4 5 6 7

class GUICentral { public Form MainForm {get;} public Form SettingsForm {get;} public Form PreviewForm {get;} public Form FolderForm {get;} }

---

C'est pas tres joli (AMHA, apres les gouts et les couleurs), mais ca fait le job. Pour ma part, je prefere ca :

Code:

---

1 2 3 4 5 6

class GUICentral { Dictionary<string, Form> m_dic = new Dictionary<string, Form>();   public Form this[string id] {get;} }

---

ca fait moins à ecrire et le fait d'id les forms par des strings est bien plus comprehensible qu'en hashant ou autres.

Apres, j'ai fait comme ca pour quelques projets recents, je ne sais pas si c'est vraiment la bonne chose, mais je n'ai pas eu pour le moment de probleme avec ca.

Oui ça me parait pas mal aussi. Que penses les autres de cette méthode ? Après-tu utilises une plutôt une classe statique ou un singleton pour cela ?

Avec le genre d'accès de la classe du dessus, c'est singleton car pas d'indexeurs sur les classes statiques (ce qui pourrait aisement etre modifié en une methode statique si tu preferes les classes statiques).

Sans vouloir rerentrer dans le sujet hautement polemique Static Vs Singleton, ici ca revient un peu (meme beaucoup) au meme, donc fais comme tu le sens. =)

Ok merci pour tes conseils. Je crois que je vais appliquer ta méthode. :)

Sinon j'ai une autre question en rapport : J'ai tout une série d'objets (bien souvent des collections) dont j'aimerais avoir accès depuis n'importe quelle classe/form de mon application. Je pensais les déclarer membre d'une classe statique, mais alors je ne peux pas faire de binding sur ces propriétés car je n'ai pas d'instance les portant. Penses-tu que l'utilisation d'un singleton conviendrait mieux ? De manière générale, doit-on utiliser un singleton chaque fois qu'on a des objets dont on veut qu'ils soient accessibles un peu partout ? Cela permet au moins la sérialisation et le binding...
Qu'en penses-tu ?

Ben en fait, comme tu le dis, meme si en apparence la classe statique et le singleton se ressemble dans l'idée (unique), la classe static a des limitations bien plus grandes que le singleton (pas d'implementation d'interface, pas d'indexeurs, pleins de limitations dues à l'aspect non-instanciables du bouzin (pour rappel, la qualificateur static n'existe pas en IL pour les classes, une classe static, c'est une classe abstract sealed)).

De maniere generale, le singleton est bien plus passe-partout que la classe static (pour les raisons evoquées plus haut). AMHA, la classe static, c'est plus un jeu d'ecriture (garantir non-instanciation, uniquement membres statics, et empecher de servir de base) pour garantir l'integrité d'une classe de methode static (les classes File et Directory dans IO par exemple sont static, Application de Forms ne l'est pas mais est sealed avec ctor private (ce qui revient au meme)).

Bref, quand tu penses variables globales, c'est le DP singleton qui doit etre envisagé en premier, et si les besoins le permettent tu peux aller vers de la classe static (mais ca n'apporte pas vraiment quelque chose en plus (ecrire les quatres lignes du DP en moins ?), surtout pour les limitations). En conclusion, toujours AMHA, la classe static peut servir pour permettre un accès global et unique mais ce n'est pas vraiment son but, le singleton a été créé uniquement dans cet optique, je te laisse tirer la conclusion. =)

Citation:

---

En conclusion, toujours AMHA, la classe static peut servir pour permettre un accès global et unique mais ce n'est pas vraiment son but

---

Alors quel est son but ? J'ai l'impression que la classe static n'a pas d'avantage propre par rapport au singleton. A part peut être les méthodes d'extensions de c# 3.0 et comme tu le dis, assurer l'intégrité des méthodes grâce au fait qu'on ne puisse pas hériter une telle classe. :roll:

J'ai aussi l'impression que la classe static sert plus à stocker des méthodes globales (entre autre à cause des raisons si dessus), tandis que le singleton se prête mieux au stockage de propriétés (on peut binder, sérialiser, faire du mapping O/R grâce à l'instance). Disons que c'est plus une conséquence de ce que sont les 2 types de classes, mais ça peut aider à s'orienter vers l'un ou l'autre. Qu'en penses-tu ?

Voila, quand tu dois travailler sur une globale, si tu n'as pas besoin d'indexeurs, de binding, de deriver, d'interface, les deux se confondent, c'est egal. Des que tu as besoin d'une des choses plus haut, la classe static ne peut plus assurer, et le singleton s'imposera de lui meme. C'est pour ca que pour une variable globale, il faut penser singleton en premier, ca te laissera une certaine latitude.

Citation:

---

mais ca n'apporte pas vraiment quelque chose en plus (ecrire les quatres lignes du DP en moins ?), surtout pour les limitations

---

Encore que l'on peut écrire une petite classe de base, si l'on n'a pas envie de les réécrire à chaque fois...

Code:

---

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

/// <summary> /// Classe de base pour un singleton avec constructeur par défaut. private ConcreteSingleton() { } /// </summary> /// <typeparam name="T">Type du singleton hérité</typeparam> public abstract class Singleton<T> where T : Singleton<T> { protected static readonly object mylock = new object(); protected static T instance;   protected Singleton() { }   public static T GetInstance() { lock ((mylock)) { if (instance == null) instance = (T)Activator.CreateInstance(typeof(T), true); return instance; } } } public class ConcreteSingleton : Singleton<ConcreteSingleton> { private ConcreteSingleton() { } }

---

Bon ça utilise la réflexion pour instancier T. Je vois pas d'autre solution pour instancier depuis l'extérieur une classe ayant un constructeur par défaut privé. Mais au niveau performance, ça ne devrait pas être trop grave parce que le singleton n'est instancié qu'une fois...