Bonjour a tous,
 
Je viens de tomber sur un problème assez important en commençant a toucher a la réflexion en C#, voici le contexte :
 
Le but de bout de code est de faire une interface de gestion des entrées / sorties de base (clavier, souris, manette ..).
Étant donne que ces 3 périphériques sont assez proches le code l'est aussi donc j'ai voulu utiliser un maximum de templates.
 
(Je développe sur XNA mais pour cet exemple j'ai fait sans).
 
J'ai donc 2 classes :
 
- LocalInputManager :
Se charge de stocker une liste de Control, de les modifier, supprimer, mettre en pause etc etc.
 
- Control :
Stock un groupe de touches liées a un évènements entre autre.
 
 
Voici un exemple :
 
LocalInputManager :  

 
Control :  

 
Et un petit main de test qui expose le probleme :

 
Le problème se situe dans la classe LocalInputManager, dans la méthode UpdateAllControls.
En effet, il ne trouve pas la méthode Update() contenue dans C, ce en quoi j'ai du mal a lui en vouloir car C est un type générique.
 
Alors la question est : Comment lui préciser que C possède bel et bien la méthode sans préciser le type car il n'y a plus d'intérêt dans ce cas ?
 
Merci pour votre aide.

Une seule solution (en gardant les types génériques) : utiliser une interface qui va définir la méthode Update. La classe Control<T> hérite alors de cette interface. Et ensuite tu rajoute ça : ITonInterfaceToto
class LocalInputManager<T, C> where C : ITonInterfaceToto, new()
Miracle !

D'ailleurs en passant, tu n'as pas besoin de faire ça :
C instance = (C)Activator.CreateInstance(typeof(C), Keys, KeyRepeat);
Sachant que tu as :
class LocalInputManager<T, C> where C : ITonInterfaceToto, new()  
Le new() spécifie que tu peux instancier la classe C dans LocalInputManager. Tu ne le fais pas, tu fais CreateInstance à la place, ce qui est moche.
Au lieu de ça, tu fais  
C instance = new C(Keys, KeyRepeat), après avoir spécifié le constructeur dans l'interface Toto

C'est génial la généricité en C#

Salut Fred82 et merci pour ta réponse rapide
 
Ton explication est claire et fonctionne parfaitement, un grand merci a toi.
 
En revanche j'avoue qu'il reste pour moi une zone d'ombre.
Je ne vois pas comment déclarer le constructeur de ma classe Control dans l'interface qui la décrit.
 
Je ne maitrise pas encore bien l'utilisation des interfaces mais étant donné qu'un constructeur prend le nom de sa classe je vois pas bien quoi mettre.
 
J'ai bien essaye INomInterface([...]); mais bon sans vraiment y croire car cela voudrait dire que je cherche a instancier l'interface :s
 
D'autant plus que ma classe Control est une classe template et qu'elle prend un type T en 1er paramètre d'un de ses constructeurs.
 
Le mot clef new sans déclaration supplémentaire ne me permet pas d'appeler autre chose que le constructeur par défaut, ce qui est assez logique.
 
Merci pour tes lumières
 
PS : Oui la puissance de ce langage m'impressionne beaucoup aussi.

 
Oui oups, ce n'est pas possible en effet (une interface ne permet pas de définir un constructeur). C'est curieux, il me semblait que je faisais un new paramétré dans mon projet actuel, je regarderai lundi.
 
Sinon tu peux aussi faire ça :
 
C instance = new C()
{
 controls = Keys,
 Repeat = KeyRepeat
};
 
En mettant les champs controls et Repeat dans l'interface qui devient finalement un classe abstraite (abstract class). Cette classe abstraite devient à son tour générique, puisque controls est d'un type générique. Le tout devient ceci :

class Program
    {
        static void Main(string[] args)
        {
            LocalInputManager<Keys, Control<Keys>> manager;
            manager = new LocalInputManager<Keys, Control<Keys>>();
            manager.AddControl("Courir droite", Keys.Right, true);
            manager.AddControl("Sauter", Keys.Space, false);
        }
    }
    public enum Keys
    {
        Left,
        Right,
        Up,
        Down,
        Space
    };
    class LocalInputManager<T, C> where C : AbstractControl<T>, new()
    {
        protected List<KeyValuePair<string, C>> controls;
        private int totalControls;
        public LocalInputManager()
        {
            this.totalControls = 0;
            this.controls = new List<KeyValuePair<string, C>>();
        }
        public void AddControl(string Name, T Keys, bool KeyRepeat)
        {
            C instance = new C()
            {
                controls = Keys,
                repeat = KeyRepeat
            };
            this.controls.Add(new KeyValuePair<string, C>(Name, instance));
            this.totalControls++;
        }
        public void UpdateAllControls()
        {
            for (int i = 0; i < this.totalControls; i++)
            {
                this.controls[i].Value.Update();
            }
        }
    }
    abstract class AbstractControl<T>
    {
        public T controls;
        public bool repeat;
        public abstract void Update();
    }
    class Control<T> : AbstractControl<T>
    {
        private new T controls;
        private new bool repeat;
        public Control()
        {
            this.repeat = false;
        }
        public Control(T Key, bool Repeat)
        {
            this.controls = Key;
            this.repeat = Repeat;
        }
        public override void Update()
        {
            Console.WriteLine("Mise a jour effectuee." );
        }
    }

Salut / re :s
 
Cette notation est très claire et agréable a l'œil, mais le seul truc qui me gêne, c'est les attributs en public en fait.

 
Si tu veux qu'ils ne soient pas exposés en dehors de ton assembly, tu peux les passer en internal ce qui aura pour effet de ne les rendre visible uniquement à l'intérieur de ton assembly ou des autres assemblies qui seraient référencées en ShowInternalsTo dans le assemblyInfo.cs

Tu te soucies un peu des perfs ?
A cet égard c'est très trèèèèès bien d'avoir pu virer la Reflection (merci la contrainte new() des generics... leur seul inconvénient c'est l'impossibilité d'utiliser un constructeur paramétré) mais ce pavé de generics et de classes abstraites c'est encore assez lourdingue.

J'ai l'impression que tu cherches à utiliser à fond les arcanes du langage faute d'en maitriser les bases... en témoigne ta premiere version qui utilisait la reflection.
J'ai un peu de mal à saisir l'ensemble des données du problèmes mais j'ai l'impression qu'avec une simple relation de polymorphisme tu pourrais alléger vachement ton implémentation.
Je n'ai pas essayé de recompiler ni rien mais à premiere vue je ne vois pas ce qui rend les generics indispensables, aussi bien C que T ?
Dans un cas tu as une classe abstraite, dans l'autre un type énuméré.

PS : simplement pour info, il est impossible de spécifier explicitement qu'un type generic est une énumération, mais tu peux lui imposer la contrainte "struct" qui limite déjà un peu les possibilités d'utilisation. Je trouve ça mieux que ne mettre aucune contrainte.

edit : et ta classe abstraite ne sert à rien on dirait, tu aurais pu utiliser une interface. Pour ce qui est de la visibilité des membres, avec les interfaces tu es contraint de tout mettre en public, ce qui est moche. Mais il y a une petite astuce (tjs pour info) : "implémenter l'interface explicitement" (je te laisse rechercher)