Récupérer un élément d'une Collection<t>

Bonsoir,

J'ai un petit soucis avec le code analysis de VS2008... Celui-ci préférant une utilisation de "Collection<T>" à la place de "List<T>", je tente donc d'essayer de le contenter.

1. La classe "Cell" représentant une cellule :

Code:

---

1 2 3 4 5 6 7

public class Cell { private string valueCell; private string width; private string height; ... }

---

2. Une méthode me permettant de récupérer une cellule (sous-entendu un objet "Cell") depuis une liste de cellules à partir de son nom :

Code:

---

1 2 3 4 5

private List<Cell> cells; public Cell GetCell (string valueCell) { return (cells.find(delegate(Cell cell) {return cell.Value.Equals(valueCell);} }

---

3. J'aimerais donc contenter l'analyseur de code en remplaçant la "List" par une "Collection". Cependant, la collection ne dispose pas de méthode permettant de récupérer un objet à partir de celle-ci. Ce que j'ai tenté :

Code:

---

1 2 3 4 5 6

private Collection<Cell> cells; public Cell GetCell (string valueCell) { int i = cells.IndexOf(delegate(Cell cell) {return cell.Value.Equals(valueCell);} return cells[i]; }

---

Mais là, j'ai droit à une erreur "Cannot convert anonymous method to type "Cell" because it is not a delegate type.

Je patauge un peu... Une idée ?

Merci d'avance :)

IndexOf ne fonctionne pas comme Find : ça prend en paramètre l'objet recherché, pas un delegate...

Donc en gros tu ne peux pas faire la même chose qu'avec une List<T>, ce qui revient à dire que l'analyseur de code t'a dit de la m**** :aie:. Il ne faut pas trop se laisser influencer par ce genre d'outils à mon avis... il peut parfois faire des suggestions "intelligentes", mais au final c'est à toi de prendre la décision : si tu préfères utiliser une List<T>, utilise une List<T>... En l'occurence je me demande pourquoi il conseille d'utiliser Collection<T> :roll:

Perso je te conseille plutôt de faire comme ça :

Code:

---

1 2 3 4 5 6 7

public Cell GetCell (string valueCell) { var result = from c in cells where c.Value == valueCell select c; return result.FirstOrDefault(); }

---

Citation:

---

Envoyé par tomlev

IndexOf ne fonctionne pas comme Find : ça prend en paramètre l'objet recherché, pas un delegate...

---

Effectivement, là est bien mon soucis ;)

Citation:

---

Envoyé par tomlev

Donc en gros tu ne peux pas faire la même chose qu'avec une List<T>, ce qui revient à dire que l'analyseur de code t'a dit de la m**** :aie:. Il ne faut pas trop se laisser influencer par ce genre d'outils à mon avis... il peut parfois faire des suggestions "intelligentes", mais au final c'est à toi de prendre la décision : si tu préfères utiliser une List<T>, utilise une List<T>... En l'occurence je me demande pourquoi il conseille d'utiliser Collection<T> :roll:

Perso je te conseille plutôt de faire comme ça :

Code:

---

1 2 3 4 5 6 7

public Cell GetCell (string valueCell) { var result = from c in cells where c.Value == valueCell select c; return result.FirstOrDefault(); }

---

---

Merci pour ton avis éclairé sur le sujet.

De plus, je trouve ta manière plus claire "à lire" que mon utilisation de délégué, à retenir :)

Citation:

---

Envoyé par tomlev

En l'occurence je me demande pourquoi il conseille d'utiliser Collection<T> :roll:

---

J'ai été confronté à cette règle il y a peu. L'explication que MSDN donne est la suivante

Citation:

---

System.Collections.Generic.List is a generic collection designed for performance not inheritance and, therefore, does not contain any virtual members. The following generic collections are designed for inheritance and should be exposed instead of System.Collections.Generic.List.

---

...mais bon, la différences n'est pas flagrante, vu que List<T> et Collection<T> implémentent exactement les mêmes interfaces :roll:

Citation:

---

System.Collections.Generic.List is a generic collection designed for performance not inheritance and, therefore, does not contain any virtual members. The following generic collections are designed for inheritance and should be exposed instead of System.Collections.Generic.List.

---

Bizarre... Si on s'en tient à cette explication, il me semble que List<T> est un meilleur choix (plus performant), à moins de vouloir faire une collection personnalisée en héritant d'une collection existante.

Ce que la MSDN dit, ce n'est n'est pas d'éviter les variables membres de type List<T> ; c'est d'éviter d'avoir des méthodes publiques qui prennent en paramètre ou renvoient des List<T>.

C'est pas pareil :)