Sélection de l'implémentation d'une classe en fonction du contexte en C#

Bonjour,

J'aimerai savoir comment réaliser des implémentations différentes d'une même classe avec la particularité suivante : l'appel des implémentations se fait de la même manière, c'est le contexte qui détermine quelle implémentation sera utilisée.

Exemple schématique :

Nous avons deux toolkit : GTK et QT, et une classe générique : UI, ainsi qu'une seule méthode : Window (pour créer une fenêtre).

Ce qui donne schématiquement :

GTK.Window
QT.Window
UI.Window

L'appel de la méthode doit se faire à partir de UI, et c'est le contexte (suis-je sur Gnome ou sur Kde) qui détermine l'utilisation de l'implémentation GTK ou QT.

À part l'utilisation d'un préprocesseurs qui changerai toutes les occurences de UI en GTK ou QT en fonction du contexte avant la compilation, je ne vois pas.

Connaissez-vous une solution plus propre en C# ? (ou autre langage .NET qui permettrait cela si nécessaire)

N'ayant pas une grande expérience de la programmation, je ne perçois pas encore toutes les possibilités de l'OO.

Merci !

salut

ton problème me fait penser au pattern FACTORY :)

A regarder sur le net !!!

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

public abstract class UI { public virtual void Window(){};   public class GTK : UI { public override void Window(){...}; }   public class QT: UI { public override void Window(){...}; }   //Si on ajoute la remarque sur la factory public enum TypeWindow{ QT, GTK }   public static class UIFactory { public static UI GetInstance(TypeWindow typeWnd) { switch(typeWnd) { case TypeWindow.GTK : return new GTK(); case TypeWindow.QT: return new QT(); } }

---

Code:

---

1 2 3

UI monUI = UIFactory.GetInstance(TypeWindow.GTK); monUI.Window();

---

Remarque :
- UI peut aussi bien être une interface...
- GTK et QT peuvent être marquées comme internal, afin d'empêcher une instanciation externe.
- Tu peux te servir de la factory pour garder des références vers des instances déjà créées, si par exemple pour chaque fenêtre tu souhaites réutiliser la même instance par type fourni
- TypeWindow étant un enum, donc un int en interne, tu peux très bien indiquer par paramètre ce que tu souhaites comme UI via les arguments du main et opérer le cast pour traiter de manière adéquate... Il est aussi possible de faire un switch sur une chaine de caractère (et donc avoir un final $: monAppli.exe GTK || $: monAppli.exe 0 [0 étant casté dans une valeur d'enum])

Merci beaucoup ! Voilà de quoi m'occuper ;)

En fait mon projet est simple. Il s'agit d'un petit exercice à but pédagogique, afin d'apprendre la progra OO sous .NET/Mono : écrire un éditeur de texte multiplateforme qui dispose d'une interface graphique qui s'adapte à l'environnement (WinForms, GTK, QT, Cocoa, Curses etc.).

L'idée n'est pas de réécrire X fois l'interface en fonction du toolkit, mais bien d'écrire une sorte de toollkit très simple de plus haut niveau qui n'est qu'une abstraction des toolkits cités précédemment à partir duquel l'interface sera écrite.

Je me contente pour l'instant de Winforms et Gtk.

Je ne sais pas où ça va me mener, mais l'idée c'est d'avoir un support concret pour apprendre la progra OO.

Jamais fait de Mono mais il y'a pas justement cette couche d'abstraction déjà integrée ?

Non, je ne crois pas. Si on veut faire du GTK on passe par GTK#, si on veut faire du Winforms par... Winforms ; du QT par Qyoto etc.

Sauf si quelque chose m'a échappé, auquel cas j'écoute les propositions des spécialistes de Mono !

Citation:

---

Envoyé par Camille_B

Non, je ne crois pas. Si on veut faire du GTK on passe par GTK#, si on veut faire du Winforms par... Winforms ; du QT par Qyoto etc.

Sauf si quelque chose m'a échappé, auquel cas j'écoute les propositions des spécialistes de Mono !

---

Ah effectivement y'a une subtilité qui m'avait échapé! Winform est cross-plateforme mais y'a d'autres librairies.

Cela dit, si tu souhaites trouver une interface dont hérite une form Qt et une forme GTK# je suis pas sur que ca existe! Or un pattern factory repose soit sur une interface qui est implémentée ou une classe de base. A moins d'heriter de tous les composants de chaque framework mais ca me parait pas top... Enfin bon j'ai jamais trop travaillé dans ces environnements donc je ne peux pas trop dire...

Oui, il s'agit bien d'hériter les composants à mesure de leur utilisation de tous les toolkit (pour le moment WF et GTK).

C'est sans doute parfaitement crados, mais mon objectif n'est pas de réaliser un produit utilisable en production. C'est juste un amusement personnel en vue d'apprendre deux ou trois trucs.

J'essaierai tout de même de faire ça le plus proprement possible ;)