Pourquoi et quand hériter de la collection

Je trace le code hérité dans mon projet écrit en C #.

Je trouve le code suivant:

public class FooCollection : Collection {}; 

Je ne comprends pas pourquoi (et quand) nous devons créer notre propre classe Collection comme celle-ci.

Pourquoi ne pas simplement utiliser la collection array ( array , List , Dictionary , …)

Quelle est la structure de données utilisée dans Collection ?? tableau? ou liste chaînée?

Je ne comprends pas pourquoi (et quand) nous devons créer notre propre classe Collection comme celle-ci.

Vous n’avez pas vraiment “besoin” de; vous pouvez simplement utiliser Collection directement, mais le fait d’avoir une classe spécifique peut améliorer la lisibilité. En outre, cela vous permet d’append un comportement spécifique pour ce type de collection. De plus, la classe Collection permet de redéfinir la plupart des opérations en redéfinissant les méthodes virtuelles. Cela vous permet de personnaliser le comportement des méthodes de collecte standard.

Pourquoi ne pas simplement utiliser la collection intégrée (tableau, Liste, Dictionnaire, …)

Un tableau a une longueur fixe, vous ne pouvez donc pas append ou supprimer des éléments; donc ce n’est pas vraiment équivalent. Dictionary associe une valeur à une clé, son objective est donc clairement différent. List peut être utilisé à la place, tant que vous n’avez pas besoin de personnaliser le comportement; cette classe n’est pas conçue pour l’inheritance, car ses méthodes ne sont pas virtuelles.

Quelle est la structure de données utilisée dans Collection ?? tableau? ou liste chaînée?

Collection agit comme une enveloppe autour d’un autre IList . Par défaut, il utilise List (qui est basé sur un tableau), mais vous pouvez passer toute autre implémentation IList au constructeur, qui l’utilisera à la place.

En déclarant que vous héritez de la classe Collection , vous déclarez que votre classe IS-A Collection , ce qui signifie que toutes ses API sont implémentées (par la classe dérivée ou par la base de la classe Collection ) .

L’avantage de l’inheritance est que vous pouvez décider de remplacer certaines des méthodes et de les gérer de la manière qui vous convient le mieux, en fonction de vos besoins ou du type T ( IFoo dans votre cas).

De la même manière, vous pouvez également décider d’étendre votre API afin de prendre en charge d’autres fonctionnalités que vous jugez appropriées à votre situation.

Par exemple, si vous IFoo ressemble à quelque chose comme ceci:

 public interface IFoo { int a; int b; } 

Dans votre classe dérivée, vous pouvez append à la suppression une surcharge qui ressemblera à ceci:

 public bool Remove(int a, int b )... 

Et cela supprimera toutes les occurrences d’éléments ayant certaines valeurs pour a et b

Je ne comprends pas pourquoi (et quand) nous devons créer notre propre classe Collection comme celle-ci.

Je ne le ferais jamais. Personnellement, je trouve la classe Collection pas utile du tout. Je n’ai pas encore trouvé d’utilisation.

L’un des principaux problèmes du type est que la plupart des méthodes ne sont pas virtuelles. Les seules méthodes virtuelles qui sont ClearItems , InsertItem , RemoveItem et SetItem (avec Equals , GetHashCode et ToSsortingng from Object ). Les autres méthodes / propriétés ne sont pas virtuelles et ne peuvent donc pas être remplacées. Cela signifie que vous pouvez modifier la sémantique pour append / insérer / supprimer un élément légèrement, mais c’est tout.

Quelle est la structure de données utilisée dans Collection ?

En interne, il s’appuie sur une List .

Pourquoi ne pas simplement utiliser la collection array ( array , List , Dictionary , …)

Dans pratiquement tous les cas, vous le feriez. Bien qu’il existe parfois des cas dans lesquels vous souhaitiez créer un nouveau type de collection, je n’ai jamais trouvé d’utilisation dans laquelle Collection était utile pour créer une telle collection personnalisée. En règle générale, il est préférable d’implémenter certaines des interfaces dans l’espace de noms Collections , en fonction de ce que votre collection peut accomplir, et éventuellement de composer le type en utilisant d’autres collections comme champs d’instance, s’il ne s’agit que d’une extension d’une collection existante.

Je ne comprends pas pourquoi (et quand) nous devons créer notre propre classe Collection comme celle-ci.

L’un des principaux cas d’utilisation de l’implémentation d’une Collection personnalisée Collection est la sérialisation.

Si vous souhaitez personnaliser le mode de sérialisation de la collection ( par exemple, en XML, à l’aide de XmlSerializable ), vous pouvez créer une classe de collection personnalisée et y implémenter IXmlSerializable . Ensuite, vous pouvez changer le mode de lecture ou d’écriture de la collection en manipulant les méthodes de Read et d’ Write de cette interface.

 class MyCollection : Collection, IXmlSerializable { public XmlSchema GetSchema() { return(null); } public void WriteXml(XmlWriter writer) { //// foreach (var item in Items) //// writer.Write... } public void ReadXml(XmlReader reader) { //// Items.Add(reader.Read... } } 

Dans la plupart des cas, cela est préférable à l’implémentation de IXmlSerializable sur la classe parente, car cela entraîne moins de code et encourage la réutilisation (vous pouvez réutiliser la même collection à plusieurs endroits et elle sera sérialisée de la même manière si vous utilisez XmlSerializer pour le sérialiser).

Je l’ai utilisé récemment en raison d’une exigence d’un système externe qui avait besoin de chaque élément de la collection pour générer un nœud XML avec l’index de l’élément ajouté.

La structure finale ressemblait un peu à ceci:

  first item second item ...  

Je ne suis pas friand de coupler la collection à la sérialisation de ce type, mais c’est parfois une approche valable.