Une variable qui référence une classe et non une instance de classe

Version imprimable

31/12/2007, 09h25
WebPac

Une variable qui référence une classe et non une instance de classe

Salut tout le monde,

ma question est plus sur le langage C# en lui-même que sur les forms, désolé de poster ici mais je n'ai pas trouvé de meilleur endroit pour la poser.

Je viens du Delphi et en Delphi il est possible de déclarer une variable et la faire pointer vers une classe, non vers un objet (une instance de la classe), en d'autres termes, je n'affecte pas un nouvel objet avec new ou un objet existant à ma variable mais la déclaration d'une classe ou d'une de ses filles.
Je n'arrive pas à faire la même chose en C#, hors comme il est bien plus récent, je pense qu'il est possible de faire la même chose.
Pour l'instant, je n'ai pas trouvé comment faire dans l'aide du C#.

Mes questions sont donc, est-ce possible ? Et si oui, comment ?

PS : pour ceux qui se demandent à quoi cela sert, voici un exemple, j'ai une classe mère Tableur qui possède certains algos, et 2 classes filles, Excel et OpenOffice qui dérivent de Tableur et qui surchargent les méthodes d'accès, de lecture et d'écriture des données dans le tableur. Je fais un projet pour Excel, un autre pour OpenOffice, au début du projet, il suffit de déclarer le type de la classe fille utilisée et chaque fois que j'ai besoin d'instancier une référence, je n'ai pas besoin de faire de if ni de switch pour savoir quel constructeur appeler.

PPS : un autre exemple d'utilisation est possible en Delphi mais pas en C# car la notion de méthode statique virtuelle n'existe pas.

Hop, je viens de réfléchir (et oui je sais que ça sert de temps en temps), je pense que j'ai une solution, un peu laborieuse peut-être mais qui devrait marcher.
Utiliser le design pattern singleton pour créer une instance de ma classe en private, l'instancier avec un constructeur statique en début de projet (donc suivant la classe fille que je désire), puis faire des méthodes statiques qui vont appeler des méthodes virtuelles de ma classe.
C'est tiré par les cheveux mais ça risque de fonctionner. Si quelqu'un a une solution plus simple, je suis preneur, si par exemple c'est nativement possible dans le langage.
31/12/2007, 09h29
Guulh

Ce qui caractérise une classe, c'est son type. Une variable Type, que tu affectes avec typeof(TaClasse) et zou. :D D'ailleurs les generics devraient également satisafire tes besoins.
31/12/2007, 09h36
Kaidan

Il faudrait p'tet penser au DP Factory.
31/12/2007, 10h00
WebPac
J'ai essayé avec Type et typeof, mais j'ai un message d'erreur à la compilation.
Voici le code que j'ai fait :
Code:

1 2 3 4 5 6 public int Test() { Type t = typeof(Tableur); t = OpenOffice; Tableur r = new t(); }
OpenOffice est une classe qui dérive de Tableur.
Le premier message d'erreur est :

Citation:

'MonEspace.OpenOffice' is a 'type' but is used like a 'variable'

Comment puis-je créer r du type OpenOffice en utilisant t ?
31/12/2007, 10h03
WebPac

Pour utiliser un DP Factory, il faut que je déclare toutes les classes filles de ma classe mère dans le DP Factory, hors je ne le souhaite pas.
J'ai un projet spécifique pour Excel et un autre pour OpenOffice.
Dans un projet, je ne souhaite pas avoir tout le code spécifique de l'autre projet, je souhaite séparer complètement les 2 projets (en tout cas leur partie spécifique).

Code:

1
2
3
 
Type t = typeof(OpenOffice);
Tableur r = Activator.CreateInstance(t);

Generics ?
Code:

1 2 3 4 5 6 private void Test<T>() where T : Tableur, new() { //.... Tableur r = new T(); //.... }
Tu appelles ensuite Test via Test<OpenOffice> ou Test<Excel>.

31/12/2007, 11h36
WebPac

Merci pour votre aide, ça m'aide beaucoup, je sais maintenant ce que je cherche.

Avec Activator.CreateInstance(t), ça fonctionne en rajoutant un cast, le seul problème dans tout ça est qu'on ne peut pas spécifier à la déclaration de t (Type t) est qu'il ne devrait pouvoir référencer que les classes Tableur et ses filles, on n'a pas de vérification mis à part lors du castage avec Activator.

Avec le code générique, je n'arrive pas à le faire fonctionner, car je dois pouvoir appeler Test en passant en paramètre <t> et non en dur, <OpenOffice> ou <Excel>.
J'ai essayé le code Test<t> et j'obtiens ce message d'erreur à la compilation :

Citation:

The type or namespace name 't' could not be found (are you missing a using directive or an assembly reference?)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
 
public class Factory {
 
   private Type type;
 
   public Factory(string type) {
      this.type = Type.GetType(type);
   }
 
   public Tableur Create() {
      return (Tableur)Activator.CreateInstance(t);
   }
 
}

et en déclarant cette factory en statique dans le code ?

31/12/2007, 11h57
Guulh

Citation:

Envoyé par WebPac

Avec le code générique, je n'arrive pas à le faire fonctionner, car je dois pouvoir appeler Test en passant en paramètre <t> et non en dur, <OpenOffice> ou <Excel>.
J'ai essayé le code Test<t> et j'obtiens ce message d'erreur à la compilation :

Mais dans une fonction Test<T>(int i), T est un paramètre, comme i. Il est un peu spécial, mais c'est un paramètre... Je n'ai pas analysé à fond ton problème, mais je ne pense pas qu'il soit tellement complexe qu'on ait besoin explicitement du type "t", dans une variable, de ta classe.

Citation:

Envoyé par Guulh

Mais dans une fonction Test<T>(int i), T est un paramètre, comme i. Il est un peu spécial, mais c'est un paramètre... Je n'ai pas analysé à fond ton problème, mais je ne pense pas qu'il soit tellement complexe qu'on ait besoin explicitement du type "t", dans une variable, de ta classe.

Je suis désolé mais quand j'essaie ton code, j'ai ce message d'erreur à la compilation :

Citation:

The type or namespace name 't' could not be found (are you missing a using directive or an assembly reference?)

Alors que t est bien déclaré ainsi

Code:

Type t = typeof(OpenOffice);

Kaidan, j'ai trouvé une méthode qui me vérifie le type pour qu'elle soit bien une classe dérivant de Tableur, finalement, on peut très bien faire la fabrique comment étant une méthode statique de Tableur :
Code:

1 2 3 4 5 6 7 8 9 10 public abstract class Tableur { public static Tableur Factory(Type t) { if (t.IsSubclassOf(typeof(Tableur))) return Activator.CreateInstance(t) as Tableur; else return null; } }
Avec t la variable initialisée au début du projet, qu'on la passe en paramètre ou bien qu'on la retrouve en global.

Citation:

Envoyé par WebPac

Je suis désolé mais quand j'essaie ton code, j'ai ce message d'erreur à la compilation :

Alors que t est bien déclaré ainsi

Code:

Type t = typeof(OpenOffice);

L'instanciation dynamique d'un type générique se fait de manière un peu particulière :
Code:

1 2 3 4 5 6 int i; Type genericDefinitionType = typeof(Test<>); Type[] typeArgs = { typeof(OpenOffice) }; Type genericType = genericDefinitionType.MakeGenericType(typeArgs); return Activator.CreateInstance(genericType, i);

Citation:
Envoyé par Greybird
L'instanciation dynamique d'un type générique se fait de manière un peu particulière :
Code:

1 2 3 4 5 6 int i; Type genericDefinitionType = typeof(Test<>); Type[] typeArgs = { typeof(OpenOffice) }; Type genericType = genericDefinitionType.MakeGenericType(typeArgs); return Activator.CreateInstance(genericType, i);
Merci pour l'info, mais finalement, on revient sur le code de départ avec l'Activator.CreateInstance, est-ce bien nécessaire d'utiliser les génériques dans ce cas ?

Salut,

Vu qu'apparement ce sont des projets distincts pourquoi ne pas jouer simplement sur des namespaces. exemple :

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
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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
#define _Excel
 
using System;
using CommonTableur;
 
#if _Excel
using Excel;
#else
using OpenOffice;
#endif
 
 
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            ITableur t = new Tableur();
            t.Machin();
            t.Truc();
        }
    }
 
 
}
 
namespace CommonTableur
{
    interface ITableur
    {
        void Truc();
        void Machin();
    }
 
}
namespace OpenOffice
 
{
    class Tableur : CommonTableur.ITableur
    {
        #region ITableur Members
        public void Truc()
        {
            Console.WriteLine("Truc Open");
        }
 
        public void Machin()
        {
            Console.WriteLine("Machin Open");
        }
        #endregion
    }
}
 
namespace Excel
{
    class Tableur : CommonTableur.ITableur
    {
        #region ITableur Members
        public void Truc()
        {
            Console.WriteLine("Truc Excel");
        }
 
        public void Machin()
        {
            Console.WriteLine("Machin Excel");
        }
        #endregion
    }
}

Si tu commentes le define en haut, ton le Tableur sera celui d'openoffice et Excel si tu laisses le define. Ici, c'est avec une interface mais on peut imaginer le meme fonctionnement avec une classe mere et des filles, chacun dans leurs namespace.

En esperant que ca aide, bon courage. =)

31/12/2007, 14h48
WebPac

Salut SirJulio,

ton idée est bonne, je me sers également des namespaces, mais le problème dans ton code est que tu instancies toujours t en Tableur (la classe mère) et non suivant une des 2 classes filles en fonction du projet (Excel ou OpenOffice), donc les méthodes Machin et Truc appeleront celles de la classe mère Tableur.

Pour reprendre le schema qu'apparement tu utilises (ici une mere abstract (deux meths abstracts), et deux filles selon le tableur) :

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
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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
#define _Excel
 
using System;
using CommonTableur;
 
#if _Excel
using Excel;
#else
using OpenOffice;
#endif
 
 
namespace ConsoleApplication1
{
    class Program
    {
        static unsafe void Main(string[] args)
        {
            Tableur t = new TableurFille();
            t.Machin();
            t.Truc();
            t.Generale();
        }
    }
 
 
}
 
namespace CommonTableur
{
    abstract class Tableur
    {
        public abstract void Truc();
        public abstract void Machin();
 
        public void Generale()
        {
            Console.WriteLine("Tableur general");
        }
    }
 
}
namespace OpenOffice
 
{
    class TableurFille : CommonTableur.Tableur
    {
        #region Tableur Members
        public override void Truc()
        {
            Console.WriteLine("Truc Open");
        }
 
        public override void Machin()
        {
            Console.WriteLine("Machin Open");
        }
        #endregion
    }
}
 
namespace Excel
{
    class TableurFille : CommonTableur.Tableur
    {
        #region Tableur Members
        public override void Truc()
        {
            Console.WriteLine("Truc Excel");
        }
 
        public override void Machin()
        {
            Console.WriteLine("Machin Excel");
        }
        #endregion
    }
}

Suivant mon define j'aurai bien la classe file souhaitée (la differenciation des filles ne se faisant pas sur le nom, puisqu'elle porte le meme, mais sur le namespace explicitement utilisé). Pas besoin d'adapter la reference utilisé pour la manip puisque les methodes specifiques sont abstracts, et suivant le define fixé à la compil tu utiliseras bien la bonne fille.

Ca me parait correspondre à la problematique, mais j'ai peut etre compris de travers. =)

31/12/2007, 15h08
Guulh

Citation:

Envoyé par WebPac

Je suis désolé mais quand j'essaie ton code, j'ai ce message d'erreur à la compilation :

Alors que t est bien déclaré ainsi

Code:

Type t = typeof(OpenOffice);

Les generics ne nécessitent pas de créer de variable de type "Type". Juste, dans un projet, tu appelles Test<Excel>, et dans un autre, Test<OpenOffice>.
31/12/2007, 15h09
WebPac

Salut,

en effet ta solution répond au problème mais elle me dérange, je ne sais pas s'il est conseillé ou déconseillé de déclarer 2 classes filles dérivant de la même mère ayant le même nom dans 2 espaces de nom différents mais ça me perturbe et je me dis que c'est source de confusion et de bug.

Je préfère continuer à travailler avec 2 filles ayant des noms explicites et différents.
31/12/2007, 15h14
Guulh
Citation:

Envoyé par WebPac

Salut,

en effet ta solution répond au problème mais elle me dérange, je ne sais pas s'il est conseillé ou déconseillé de déclarer 2 classes filles dérivant de la même mère ayant le même nom dans 2 espaces de nom différents mais ça me perturbe et je me dis que c'est source de confusion et de bug.

Je préfère continuer à travailler avec 2 filles ayant des noms explicites et différents.

A ce moment là, tu peux utiliser un autre aspect de "using" :
Code:

1 2 3 4 5 #if Excel using ClasseFille = Excel.ClasseMachin; #else using ClasseFille = OpenOffice.ClasseBidule; #endif
31/12/2007, 15h18
WebPac

Citation:

Envoyé par Guulh

Les generics ne nécessitent pas de créer de variable de type "Type". Juste, dans un projet, tu appelles Test<Excel>, et dans un autre, Test<OpenOffice>.

Ok mais ça pose problème car justement je dois pouvoir l'appeler sans mettre en dur une classe.
31/12/2007, 15h22
SirJulio

Citation:

Envoyé par WebPac

Ok mais ça pose problème car justement je dois pouvoir l'appeler sans mettre en dur une classe.

Je comprends pour le namespace-trick. =)

Mais pour revenir au probleme, si tu ne le specifies pas en dur, comme et à quel moment doit etre differenciée la classe à instancier ? Tu seras bien obligé à un moment ou à un autre de specifier en dur la fille, non ?
31/12/2007, 15h28
Guulh

Citation:

Envoyé par SirJulio

Je comprends pour le namespace-trick. =)

Mais pour revenir au probleme, si tu ne le specifies pas en dur, comme et à quel moment doit etre differenciée la classe à instancier ? Tu seras bien obligé à un moment ou à un autre de specifier en dur la fille, non ?

J'opine. Que ce soit en créant une variable (pointant sur un type), en créant une classe générique ou avec des #define, c'est pareil, non ? Dans les trois cas, il n'y a qu'une ligne à changer pour passer de l'un à l'autre.
31/12/2007, 15h31
WebPac

Citation:

Envoyé par SirJulio

Je comprends pour le namespace-trick. =)

Mais pour revenir au probleme, si tu ne le specifies pas en dur, comme et à quel moment doit etre differenciée la classe à instancier ? Tu seras bien obligé à un moment ou à un autre de specifier en dur la fille, non ?

Tout à fait, mais je ne le souhaite devoir le faire qu'une fois au tout début du projet et dans une partie spécifique au projet et non dans le code commun.
Les 2 projets ont beaucoup de partie commune (presque la totalité), sauf la déclaration du projet en elle même et la partie spécifique d'accès au tableur.

Je souhaite donc faire cette différenciation au lancement du projet, dans un code d'instanciation de l'application, je n'ai pas encore trouvé exactement où, j'ai pensé le mettre dans le constructeur statique de chaque classe fille afin de ne pas avoir à le mettre en dur au début du projet et que ce soit toujours appelé (exemple, si les classes sont réutilisées dans d'autres projets).

Dans la version 2005, la partie qui créait la form principale puis la lançait n'était pas dans un code généré automatiquement, dans la version 2008 avec XAML, cette partie est générée automatiquement, je pense qu'il existe un événement que je pourrais récupérer pour faire cette différenciation (si je ne la fais pas dans le constructeur statique).
31/12/2007, 16h04
SirJulio

Citation:

Envoyé par WebPac

Dans la version 2005, la partie qui créait la form principale puis la lançait n'était pas dans un code généré automatiquement, dans la version 2008 avec XAML, cette partie est générée automatiquement, je pense qu'il existe un événement que je pourrais récupérer pour faire cette différenciation (si je ne la fais pas dans le constructeur statique).

Pour le probleme de l'intialisation, attache toi à l'event StartUp de ton App, il sera appelé à l'instanciation de ton App. Dans ce callback, tu pourras assigner la bonne fille à une variables tableur.
31/12/2007, 16h52
WebPac

Citation:

Envoyé par SirJulio

Pour le probleme de l'intialisation, attache toi à l'event StartUp de ton App, il sera appelé à l'instanciation de ton App. Dans ce callback, tu pourras assigner la bonne fille à une variables tableur.

En effet, j'ai trouvé en tatonnant dans le XAML de l'app pour trouver cet événement (espérons qu'ils rajoutent les évéments dans l'inspecteur d'objet XAML).

Le problème en utilisant les #if #else .. est que le #define n'a pas la portée du projet entier mais juste de l'unité dans laquelle il est définit.
Cela voudrait dire que pour toutes les unités communes, je devrais écrire #define _Excel pour compiler le projet pour Excel, puis toutes les changer pour compiler le projet pour OpenOffice, autant dire que ce n'est pas qu'une ligne et le travail serait à faire à chaque changement de projet.
A moins qu'il n'existe un moyen de le déclarer au niveau d'un projet mais je n'ai pas encore trouvé cette possibilité.
31/12/2007, 17h07
SirJulio

Citation:

Envoyé par WebPac

Le problème en utilisant les #if #else .. est que le #define n'a pas la portée du projet entier mais juste de l'unité dans laquelle il est définit.
Cela voudrait dire que pour toutes les unités communes, je devrais écrire #define _Excel pour compiler le projet pour Excel, puis toutes les changer pour compiler le projet pour OpenOffice, autant dire que ce n'est pas qu'une ligne et le travail serait à faire à chaque changement de projet.
A moins qu'il n'existe un moyen de le déclarer au niveau d'un projet mais je n'ai pas encore trouvé cette possibilité.

Le define peut se faire dans les propriétés du projet (build => conditional compilation symbols) pour une constante "projectwide". =)

Citation:

Envoyé par SirJulio

Le define peut se faire dans les propriétés du projet (build => conditional compilation symbols) pour une constante "projectwide". =)

Merci, je me disais bien aussi que ça devait être possible, reste à trouver où.

Il n'empêche qu'avec la solution des #if #else, il faut non seulement, déclarer le #using en tête de chaque fichier qui est succeptible d'utiliser une classe fille, mais aussi quand on souhaite compiler les 2 projets, on est obligé de faire une reconstruction complète, sans quoi, des unités sont compilées avec la mauvaise #using.
De plus, le jour où il y aurrait une nouvelle fille, PDF par exemple, il faudra reprendre toutes les unités communes pour rajouter un #else if pour mettre #using = PDF. Vous me direz, cela n'arrive rarement, c'est vrai, mais le but d'une unité commune, c'est de ne rien connaître des unités spécifiques et avec cette méthode, pré-procession, elles y sont toutes et à la compilation, il y en a 1.

Mise à part ce point, le fait qu'il faille reconstruire est quand même blocant.

Pour finir avec tous ces tests, avec des classes et méthodes génériques, je n'ai pas réussi à le faire fonctionner.

La meilleure solution trouvée pour l'instant est d'utiliser une fabrique méthode statique de la classe mère Tableur qui fait :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 public abstract class Tableur { public static Type _Type; public abstract string Test(); public static Tableur Factory() { if (_Type.IsSubclassOf(typeof(Tableur))) return Activator.CreateInstance(_Type) as Tableur; else return null; } }
Avec initialisation de la variable _Type, soit dans le constructeur statique dans chaque classe fille (problème car on ne peut pas appeler le constructeur statique lorsqu'on le souhaite, il s'appelle un peu quand il veut et en testant, je l'ai vu s'appeler trop tard).
Ou initialisation de la variable _Type dans l'événement Application_Startup de chaque projet.

Merci en tout cas à tous ceux qui ont participé au sujet d'avoir pris de leur temps et fait chauffer leurs neurones un 31 décembre.

Et bonne année à tout le monde !

03/01/2008, 11h07
WebPac

Salut,
j'ai trouvé une solution qui n'utilise pas la réflexion mais uniquement les concepts de la POO, je vous la donne pour information, elle utilise le Design Pattern Abstract Factory.

Dans la classe Tableur, déclarer une classe protégée abstraite Fabrique.
Surcharger cette classe Fabrique dans les 2 classes filles de Tableur, FabriqueXL et FabriqueOOo.
Déclarer une variable statique Fabrique dans la classe Tableur.
Faire une méthode d'initialisation qui crée la variable statique en FabriqueXL ou FabriqueOOo dans la partie Startup du projet (donc dans une partie spécifique).
Puis déclarer une méthode statique publique dans Tableur nommée Factory qui appelle une méthode virtuelle qui crée l'instance du Tableur.

Je ne sais pas si j'ai été clair. C'est un peu plus complexe que l'autre solution, mais ça n'utilise que les concepts de POO sans avoir besoin de réflexion.