Benutzerdefinierte Sammlung mit IEnumerable vs ICollection vs IList
Muss ich das design für meine eigenen GenericCollection
Klasse. Jetzt habe ich viele Möglichkeiten abzuleiten, es mit IEnumerable
ICollection
und IList
wo später bietet einige neue Funktionen.
Ich bin etwas verwirrt, wenn ich mit IEnumerable<T>
könnte ich verlangen, das Objekt deklarieren, um tatsächlich halten Sie die Kollektion wie in diesem Fall _list
.
public class GenericCollection<T> : IEnumerable<T>
{
private List<T> _list;
//...
}
Aber wenn ich mit ICollection<T>
oder IList<T>
ich fordere nicht zu erklären, dass die List
Objekt, wie es ist implizit verfügbar.
public class GenericCollection<T> : IList<T>
{
//no need for List object
//private List<T> _list;
//...
}
Was ist der Unterschied zwischen diesen beiden Ansätzen mit Bezug auf Leistung?
In dem Szenario jeweils bevorzugt, besonders, wenn es um die Gestaltung Ihrer eigenen Kollektion. Ich interessiere mich für das geringe Gewicht Sammlung mit guter Leistung. Ich denke, dies kann erreicht werden durch IEnumerable<T>
aber wie das genau zusammen mit einigen starke Gründe, mit ihm zu gehen?
Ich überprüft haben einige bereits bestehende posten, aber keiner gibt erforderlichen Informationen.
Rückkehr 'IList' vs 'ICollection' vs 'Sammlung'
InformationsquelleAutor der Frage Furqan Safdar | 2012-10-31
Du musst angemeldet sein, um einen Kommentar abzugeben.
IEnumerable
ICollection
undIList
(im Allgemeinen kann jeder Typ mit einemI
Präfix) sind nur Schnittstellen. Lassen Sie Sie zeigen, was deine Klasse tun wird, aber im Gegensatz zu, wenn Sie Erben eine Klasse, die Schnittstellen nicht bieten Ihnen eine default-Implementierung von beliebigen der Dinge, die Sie sagen, Sie tun müssen.So weit wie die Auswahl, welche Schnittstelle, hier ist eine kurze Anleitung:
IList
ist einICollection
zugegriffen werden kann, die durch den index.ICollection
ist einIEnumerable
mit einfachem Zugang zu Dingen wieAdd
Remove
undCount
.IEnumerable
ist alles, was aufgelistet werden können, auch wenn die Liste derer Dinge, die nicht existieren, bis Sie aufzählen.Einige Klassen, die Sie vielleicht zu erweitern (oder zu halten als ein eigenes Feld läuft, dass die meisten der Logik) für Ihre Sammlung sind
List<T>
Collection<T>
(implementiertIList<T>
aber mit einfacheren Zugang zu überschreiben Umsetzung, siehe Sammlung<T> versus List<T> was sollten Sie auf Ihre Schnittstellen? für die großen Unterschiede, die zwischen diesen beiden)ObservableCollection<T>
oder Sammlungen, die nicht Listen, wieDictionary<T, U>
undHashSet<T>
. Für mehr info über diesen, suchen Sie in der MSDN-Dokumentation für die Klasse.InformationsquelleAutor der Antwort Tim S.
First off, müssen Sie nicht haben, um tatsächlich wählen Sie zwischen diese Schnittstellen, wenn es notwendig ist, die Sie implementieren können, alle drei. Zweite Implementierung der IEnumerable-Schnittstelle ist es nicht erforderlich, um die zugrunde liegende Liste der öffentlichkeit. Sie implementieren können, nur die Methoden zu verwenden, den Zähler der zugrunde liegenden Liste.
Performancewise, bezweifle ich, es werden viel Einfluss auf das konzentrieren, was Sie brauchen, funktional. Der einzige Weg, um sicher wissen, ist, zu Messen.
InformationsquelleAutor der Antwort Rik
Die Leistung ist unwahrscheinlich, dass abhängig davon, welche Schnittstellen implementiert werden. Es hängt vielmehr davon ab, wie viele Anweisungen der Prozessor ausführen muss, um ein bestimmtes Ziel zu erreichen. Wenn Sie IEnumerable implementieren und wickeln Sie über die Liste, sind Sie wahrscheinlich, um am Ende das schreiben Hinzufügen/Entfernen/[] Methoden, die nur die Vermehrung der Anrufe auf die Liste, das würde noch ein performance-overhead. Daher, obwohl ich gar keine Messungen, die Vererbung Ansatz wäre wahrscheinlich ein ganz kleines bisschen schneller.
Jedoch, solche details in der Regel egal, nur für die real-time-Anwendungen mit einem extrem sparen müssen alle möglichen CPU-Zyklus. Eric Lippert hat einen tollen Artikel über Aufmerksamkeit auf solche details: http://blogs.msdn.com/b/ericlippert/archive/2003/10/17/53237.aspx. Im Allgemeinen, sind Sie wahrscheinlich besser dran mit dem Ansatz, der besser passt business-Logik und die Architektur Ihrer Anwendung, eher als performance-details.
InformationsquelleAutor der Antwort Andrew Sklyarevsky