Discussion :

[Seb02859]

Bonjour,

Il y a un truc que je ne comprend pas sur les génériques... Si quelqu'un voulait bien m'expliquer ce serait gentil...

J'ai un "Catalogue<T>" où "T" est une classe dérivant obligatoirement de "ElementCatalogue".

"ElementCatalogue" a par exemple deux classe filles "ElementCatalogueMeubles" et "ElementCataloguePieces".

Si je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Catalogue<ElementCatalogue> catalogue = new Catalogue<ElementCataloguePieces>();

Pourquoi ai-je une erreur ?

Quel serait alors la bonne pratique a mettre en place ?

[Pol63]

question qui passe de temps en temps, certains parlent de covariance ou autre ...

enfin ce qu'il y a à retenir c'est que même si B hérite de A et que B peut etre rangé dans une variable de type A
une collection B n'a rien à voir avec une collection de A, les élements d'une collection de B pourrait rentrer dans un collection de A certes mais ca s'arrête là

soit tu types sur <A> soit sur <B> mais l'instance doit correspondre au type
le type n'est pas catalogue mais bien catalogue<T>



après rien n'empeche de filtrer avec .OfType par exemple pour n'avoir que ceux d'un type

[Sehnsucht]

Personnellement je ne comprends pas pourquoi catalogue est générique en premier lieu.
Elle semble devoir contenir un ensemble de ElementCatalogue, ceux-ci pouvant aussi bien être des ElementCataloguePieces que des ElementCatalogueMeubles. Ça reste à une simple composition pour moi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class Catalogue
{
    private List<ElementCatalogue> elements;
 
    //...
    public void Add (ElementCatalogue element)
    {
        elements.Add (element);
    }
}

Du point de vue de la méthode Add, qu'on lui donne ElementCatalogue, ElementCataloguePieces ou ElementCatalogueMeubles ça ne fait aucune différence

[Pragmateek]

Par défaut la généricité n'est en effet pas covariante.

Pour ce faire il faut passer par des interfaces et spécifier la nature covariante via out :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
interface ICatalogue<out T>
{
    ...
}
 
class Catalogue<T> : ICatalogue<T>        
{
    ...
}
 
....
 
ICatalogue<ElementCatalogue> catalogue = new Catalogue<ElementCataloguePieces>();

[DonQuiche]

Pourquoi ai-je une erreur ?

Parce que si cela ait été autorisé il deviendrait licite d'assigner un ElementCataloguePieces à une collection d'ElementCatalogueMeubles castée en collection d'ElementCatalogue !

De deux choses l'une :
* Soit tu n'as besoin de ce cast que pour un accès en lecture et alors une interface covariante est la bonne réponse. C'est par exemple le cas d'IEnumerable (il est licite de caster un IEnumerable<ElementCatalogueMeubles> en IEnumerable<ElementCatalogue>), IReadOnlyCollection<T> et IReadOnlyList<T>.

* Ou alors tu as bel et bien besoin d'un accès en écriture et dans ce cas soit tu as une erreur de conception, soit tu es obligé de recourir à une sale ficelle pour te sortir d'une ornière, auquel cas une interface non-générique commune IElementCatalogue { void Add(ElementCatalogue) } est la meilleure chose à faire. Mais je t'invite à d'abord à vérifier ta conception.

[Seb02859]

Merci des réponses, je me penche de nouveau sur le problème.

Personnellement je ne comprends pas pourquoi catalogue est générique en premier lieu.
Elle semble devoir contenir un ensemble de ElementCatalogue, ceux-ci pouvant aussi bien être des ElementCataloguePieces que des ElementCatalogueMeubles. Ça reste à une simple composition pour moi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class Catalogue
{
    private List<ElementCatalogue> elements;
 
    //...
    public void Add (ElementCatalogue element)
    {
        elements.Add (element);
    }
}

Du point de vue de la méthode Add, qu'on lui donne ElementCatalogue, ElementCataloguePieces ou ElementCatalogueMeubles ça ne fait aucune différence

En fait à la base la classe catalogue n'est censé n'avoir qu'un type d'élément catalogue "ElementCataloguePieces" ou "ElementCatalogueMeubles" mais pas les deux !



Je n'ai pas totalement compris la notion de la covariance, je vais de ce pas faire quelques recherches.


Je pense qu'il s'agit d'une erreur de conception, je n'ai pas eu l'occasion de faire beaucoup de conception et il est fort probable que l'erreur vienne de la...



Il me faudrait alors peut être faire un tableau contenant tous les Catalogue<ElementCataloguePieces> et Catalogue<ElementCatalogueMeubles>.
Une classe ICatalogue permettant de faire un tableau serait-elle une bonne solution ?

[Pragmateek]

Non tu n'as pas nécessairement d'erreur de conception.

Sinon on peut considérer que la plupart des langages en ont fait une énorme en permettant d'avoir string[], int[], double[]... alors qu'on peut se contenter d'object[] !
Il ne faut pas confondre généricité et polymorphisme.

Et si Microsoft a dépensé des sous pour implémenter la covariance c'est que c'était vraiment un besoin très important de la communauté des développeurs.
(Sache que développer la moindre feature coûte une blinde c'est pour ça que de nombreuses features n'ont jamais été implémentées même si le besoin est bien là : un sou est un sou.)
Et en effet j'ai eu plusieurs fois besoin de me servir de cette covariance.

Après tu peux parfois t'en passer et "feinter" : e.g. si ton catalogue implémente IEnumerable<T> alors tu bénéficies de la covariance de l'interface IEnumerable<T> sans avoir à implémenter toi même une interface dédiée comme je l'ai fait.
Mais dans ce cas tu es limité au contrat d'IEnumerable<T> donc à voir si les traitements qui utilisent les Catalogues peuvent s'en contenter.