Classes différenciées par le type d'une seule variable membre et ObservableCollection

Bonjour,

J'ai une ObservableCollection servant de source à un DataGrid.
Le truc, c'est que les objets contenus dans mon ObservableCollection sont de types quasiment identiques.
En effet, ils ne diffèrent que par le type d'une seule variable membre.

Du coup, je me suis dit, on va utiliser les classes génériques et faire ça :

Code:

---

1 2 3 4 5 6 7

public class Parameter<T> { private string name; private T value; ... }

---

Malheureusement, quand j'essaie de créé mon ObservableCollection de Parameter, j'ai une erreur de compil et je ne sais pas comment la déclarer (et si c'est possible).
J'ai essayé ça :

Code:

---

1 2 3 4 5

ObservableCollection<Parameter> params; ObservableCollection<Parameter<?>> params; ObservableCollection<Parameter<T>> params; ObservableCollection<Parameter<>> params;

---

Quelqu'un aurait une idée ?

Merci d'avance.

PS : j'ai aussi pensé à utiliser une classe-mère contenant tous les attributs communs et des classes filles n'ajoutant que la variable dont le type diffère, mais ça ne me paraît pas top...

Ce n'est pas possible. Même si les types sont "quasiment identiques", ils ne sont pas compatibles pour autant... du point de vue du compilateur ce sont des types tout à fait différents.

Citation:

---

Envoyé par tomlev

Ce n'est pas possible. Même si les types sont "quasiment identiques", ils ne sont pas compatibles pour autant... du point de vue du compilateur ce sont des types tout à fait différents.

---

Mais c'est pour cela qu'il a créé une classe générique Parameter<T> avec T étant le membre variant.

Donc une déclaration de type

Code:

---

1 2	ObservableCollection<Parameter<string>> myCollection;

---

est valide.

J'avoue que je ne vois pas bien où il a un problème

(à moins qu'il ait vraiment utilisé params comme nom de variable, mais je ne pense pas quand même :P )

Citation:

---

Envoyé par Bluedeep

Donc une déclaration de type

Code:

---

1 2	ObservableCollection<Parameter<string>> myCollection;

---

est valide.

---

Oui, je suis d'accord avec ça... ce que je dis, c'est qu'on ne peut pas avoir une ObservableCollection qui contient à la fois des Parameter<string>, des Parameter<int>, des Parameter<toto>, etc... Tous les éléments doivent être de même type, ou du moins avoir un type de base commun. Dans ce cas, le seul "ancêtre" commun est le type Object...

Citation:

---

Envoyé par tomlev

Oui, je suis d'accord avec ça... ce que je dis, c'est qu'on ne peut pas avoir une ObservableCollection qui contient à la fois des Parameter<string>, des Parameter<int>, des Parameter<toto>, etc... Tous les éléments doivent être de même type, ou du moins avoir un type de base commun. Dans ce cas, le seul "ancêtre" commun est le type Object...

---

Ok, j'avais pas perçu correctement son problème.

Oui, effet, dans ce cas il suffit qu'il fasse une classe

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

class ParameterBase { // tous ses champs communs // ......... }   class Parameter<T> : ParameterBase { T _MySpecificField; }   ObservableCollection<ParameterBase> myCollection;

---

ah oui tiens, j'avais même pas pensé à ça...
Mais dans ce cas, ce n'est pas très pratique à manipuler, car on n'a pas directement accès au champ dont le type varie à partir du type ParameterBase. On pourrait ajouter dans cette classe une propriété Object, qui serait redéfinie dans Parameter<T> :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class ParameterBase { public string Name { get; set; } public object Value { get; set; } }   class Parameter<T> : ParameterBase { new public T Value { get { return (T)base.Value; } set { base.Value = value; } } }

---

Comme ça, quand on manipule un ParameterBase, Value renvoie un object, et quand on manipule un Parameter<T>, Value renvoie un T

Citation:

---

Envoyé par tomlev

ce que je dis, c'est qu'on ne peut pas avoir une ObservableCollection qui contient à la fois des Parameter<string>, des Parameter<int>, des Parameter<toto>, etc...

---

C'est bien à ça que je veux arriver...

Je testerai votre solution demain matin.

Question supplémentaire : cette syntaxe, c'est une surcharge de propriété, c'est ça ?

Code:

---

1 2 3 4 5 6

new public T Value { get { return (T)base.Value; } set { base.Value = value; } }

---

Non :)

La surcharge c'est le fait de définir plusieurs méthodes de même nom mais avec des paramètres différents.

Le new dans ce cas de figure sert à masquer un membre hérité, cf. MSDN ;)

Citation:

---

Envoyé par seiryujay

Question supplémentaire : cette syntaxe, c'est une surcharge de propriété, c'est ça ?

---

Citation:

---

Envoyé par StormimOn

Non :)

La surcharge c'est le fait de définir plusieurs méthodes de même nom mais avec des paramètres différents.

Le new dans ce cas de figure sert à masquer un membre hérité, cf. MSDN ;)

---

Pour être plus précis :

- le modificateur override permet de redéfinir l'implémentation d'une méthode ou propriété virtuelle de la classe de base. C'est le principe du polymorphisme : la méthode qui sera appelée est déterminée à l'exécution, selon le type réel de l'objet (même si le type de la variable est celui de la classe de base). La signature de la méthode redéfinie doit être la même que dans la classe de base

- le modificateur new permet de masquer une méthode ou propriété de la classe de base, en définissant une nouvelle méthode ou propriété de même nom, mais avec une signature différente. Ce n'est pas une méthode polymorphe : elle ne sera pas appelée qu'à partir d'une variable du type de la classe où elle est définie (ou d'une classe héritée).

Citation:

---

Envoyé par tomlev

Comme ça, quand on manipule un ParameterBase, Value renvoie un object, et quand on manipule un Parameter<T>, Value renvoie un T

---

Oui, mais dans la mesure où l'exploitation de l'objet suppose d'examiner le type réel de l'instance, cela n'apporte pas grand chose de plus, même si c'est parfaitement valide (entre examiner le type de l'objet ou examiner le type de l'instance container ...)

Citation:

---

Envoyé par Bluedeep

Oui, mais dans la mesure où l'exploitation de l'objet suppose d'examiner le type réel de l'instance, cela n'apporte pas grand chose de plus, même si c'est parfaitement valide (entre examiner le type de l'objet ou examiner le type de l'instance container ...)

---

Ah ben oui en fait, je suis trop dans les chous...
La semaine a été rude, soyez indulgents avec moi :roll:

Et merci pour les infos sur l'opérateur new.