Warum und wann von CollectionT erben soll

  

Ich verstehe nicht, warum (und wann) wir unsere eigene Collection-Klasse erstellen müssen.

Sie brauchen nicht wirklich "zu"; Sie könnten einfach Collection<IFoo> direkt verwenden, aber eine bestimmte Klasse kann die Lesbarkeit verbessern. Außerdem können Sie ein bestimmtes Verhalten für diesen Sammlertyp hinzufügen. Außerdem ermöglicht die Klasse Collection<T> , dass die meisten Operationen durch Überschreiben virtueller Methoden neu definiert werden. Dadurch können Sie das Verhalten der Standard-Sammlungsmethoden anpassen.

  

Warum nicht einfach die integrierte Sammlung verwenden (Array, Liste, Wörterbuch, ...)

Ein Array hat eine feste Länge, sodass Sie keine Objekte hinzufügen oder entfernen können. also ist es nicht wirklich gleichwertig. Dictionary<K,V> assoziiert einen Wert mit einem Schlüssel, also hat er einen eindeutig anderen Zweck. List<T> könnte stattdessen verwendet werden, solange Sie das Verhalten nicht anpassen müssen. Diese Klasse ist nicht für die Vererbung ausgelegt, da ihre Methoden nicht virtuell sind.

  

Welche Datenstruktur wird in Collection verwendet? Array? oder verknüpfte Liste?

Collection<T> fungiert als Wrapper um ein anderes IList<T> . Standardmäßig verwendet es eine List<T> (die auf einem Array basiert), aber Sie können jede andere IList<T> -Implementierung an den Konstruktor übergeben, und stattdessen wird diese verwendet.

Indem Sie angeben, dass Sie die Klasse Collection<T> erben, deklarieren Sie Ihre Klasse IS-A Collection<T> , was bedeutet, dass Sie alle API implementiert haben (entweder durch die abgeleitete Klasse oder durch die Basis die Klasse Collection<T> ).

Der Vorteil der Vererbung besteht darin, dass Sie einige der Methoden überschreiben und sie so behandeln können, dass Sie besser auf Ihre Bedürfnisse oder den Typ T ( IFoo in Ihrem Fall) reagieren.

Auf die gleiche Weise können Sie auch entscheiden, Ihre API zu erweitern, um einige andere Funktionen zu unterstützen, die Sie für Ihre Situation passend finden.

Wenn Ihre Klasse IFoo beispielsweise so aussieht:

In Ihrer abgeleiteten Klasse können Sie dem Entfernen das wird etwa so aussehen:

Und es werden alle Vorkommen von Elementen entfernt, die bestimmte Werte für a und b

  

Ich verstehe nicht, warum (und wann) wir unsere eigene Collection-Klasse erstellen müssen.

Ich würde es nie tun. Ich persönlich finde die Klasse Collection überhaupt nicht nützlich. Ich habe noch keine Verwendung dafür gefunden.

Eines der Hauptprobleme beim Typ ist, dass die meisten Methoden nicht virtuell sind. Die einzigen virtuellen Methoden, die ClearItems , InsertItem , RemoveItem und SetItem (zusammen mit Equals , GetHashCode und ToString von Object ) sind. Der Rest der Methoden / Eigenschaften ist nicht virtuell und kann daher nicht überschrieben werden. Dies bedeutet, dass Sie die Semantik zum Hinzufügen / Einfügen / Entfernen eines Elements leicht ändern können, aber das ist alles.

  

Welche Datenstruktur wird in Collection<T> verwendet?

Intern wird es von List<T> unterstützt.

  

Warum nicht einfach die integrierte Sammlung verwenden ( array , List<T> , Dictionary<K,V> , ...)

In fast allen Fällen würdest du das tun. Während es gelegentlich Fälle gibt, in denen Sie tatsächlich einen neuen Sammlungs-Typ erstellen möchten, habe ich noch nie eine Verwendung gefunden, bei der Collection<T> beim Erstellen einer solchen benutzerdefinierten Sammlung hilfreich war. Im Allgemeinen ist es am besten, einige der Schnittstellen im Namespace Collections zu implementieren, basierend darauf, was Ihre Sammlung erfüllen kann, und optional den Typ mit anderen Sammlungen als Instanzfelder zu erstellen, wenn es sich lediglich um eine Erweiterung einer vorhandenen Sammlung handelt. p>     

  

Ich verstehe nicht, warum (und wann) wir unsere eigene Collection-Klasse erstellen müssen.

Einer der wichtigsten Anwendungsfälle für die Implementierung einer benutzerdefinierten Collection<T> ist die Serialisierung.

Wenn Sie anpassen möchten, wie die Sammlung serialisiert wird ( zum Beispiel nach XML mit XmlSerializable ), können Sie eine benutzerdefinierte Erfassungsklasse erstellen und IXmlSerializable darauf implementieren. Anschließend können Sie ändern, wie die Sammlung gelesen oder geschrieben wird, indem Sie die Methoden Read und Write dieser Schnittstelle bearbeiten.

Dies ist in den meisten Fällen besser als die Implementierung von IXmlSerializable in der übergeordneten Klasse, da es insgesamt zu weniger Code führt und die Wiederverwendung fördert (Sie können dieselbe Sammlung an mehreren Stellen wiederverwenden und sie wird auf die gleiche Weise serialisiert Solange Sie ein XmlSerializer verwenden, um es zu serialisieren).

Ich habe dies kürzlich aufgrund einer Anforderung von einem externen System verwendet, das jedes Element der Sammlung benötigt hat, um einen XML-Knoten mit dem Index des angehängten Elements zu erzeugen.

Die endgültige Struktur sah ungefähr so ​​aus:

Ich mag es nicht, die Sammlung so mit der Serialisierung zu koppeln, aber manchmal ist es ein gültiger Ansatz.