Sammlung <T> versus Liste <T> Was sollten Sie auf Ihren Schnittstellen verwenden?

Der Code sieht wie folgt aus:

namespace Test
{
    public interface IMyClass
    {
        List<IMyClass> GetList();
    }

    public class MyClass : IMyClass
    {
        public List<IMyClass> GetList()
        {
            return new List<IMyClass>();
        }
    }
}

Wenn ich die Code-Analyse durchführe, erhalte ich die folgende Empfehlung.

Warnung 3 CA1002: Microsoft.Design: Ändern Sie 'Liste' in 'IMyClass.GetList ()', um Collection, ReadOnlyCollection oder KeyedCollection zu verwenden

Wie soll ich das beheben und was ist hier eine gute Praxis?

Um den "Warum" -Teil der Frage zu beantworten, warum nicht List<T>, sind die Gründe zukunftssicher und API-Einfachheit.

Zukunftssicher

List<T>ist nicht so konzipiert, dass es durch Unterklassen leicht erweiterbar ist; Es ist so konzipiert, dass es für interne Implementierungen schnell ist. Sie werden bemerken , die Methoden auf nicht virtuell sind und so nicht außer Kraft gesetzt werden kann, und es gibt keine Haken in seine Add/ Insert/ RemoveOperationen.

Dies bedeutet, dass Sie den Typ ändern müssen, wenn Sie das Verhalten der Auflistung in Zukunft ändern müssen (z. B. um Nullobjekte abzulehnen, die von Personen hinzugefügt werden sollen, oder um zusätzliche Arbeiten auszuführen, wenn dies geschieht, z. B. das Aktualisieren Ihres Klassenstatus) Von der Sammlung kehren Sie zu einer Unterklasse zurück, die eine brechende Schnittstellenänderung darstellt (natürlich kann das Ändern der Semantik von Dingen wie dem Nichtzulassen von Null auch eine Schnittstellenänderung sein, aber Dinge wie das Aktualisieren Ihres internen Klassenstatus wären dies nicht).

Wenn Sie also entweder eine Klasse zurückgeben, die leicht in Unterklassen wie Collection<T>oder eine Schnittstelle wie unterteilt werden kann IList<T>, ICollection<T>oder IEnumerable<T>Ihre interne Implementierung so ändern können, dass sie Ihren Anforderungen entspricht, ohne den Code der Verbraucher zu beschädigen, da sie weiterhin als zurückgegeben werden kann der Typ, den sie erwarten.

API-Einfachheit

List<T>enthält viele nützliche Funktionen wie BinarySearch, Sortund so weiter. Wenn es sich jedoch um eine Sammlung handelt, die Sie verfügbar machen, steuern Sie wahrscheinlich die Semantik der Liste und nicht die Verbraucher. Während Ihre Klasse diese Operationen möglicherweise intern benötigt, ist es sehr unwahrscheinlich, dass Verbraucher Ihrer Klasse sie anrufen möchten (oder sollten).

Indem Sie eine einfachere Sammlungsklasse oder -schnittstelle anbieten, reduzieren Sie die Anzahl der Mitglieder, die Benutzer Ihrer API sehen, und erleichtern ihnen die Verwendung.

Ich würde persönlich erklären, dass es sich eher um eine Schnittstelle als um eine konkrete Sammlung handelt. Wenn Sie wirklich Listenzugriff wünschen, verwenden Sie IList<T>. Andernfalls berücksichtigen Sie ICollection<T>und IEnumerable<T>.

Ich glaube, noch hat niemand den "Warum" -Teil beantwortet ... also los geht's. Der Grund, warum "Sie" a Collection<T>anstelle von a verwenden sollten, List<T>liegt darin, dass List<T>jeder, der Zugriff auf Ihr Objekt erhält, die Elemente in der Liste ändern kann, wenn Sie a verfügbar machen . Während Collection<T>soll anzeigen, dass Sie Ihre eigenen Methoden "Hinzufügen", "Entfernen" usw. erstellen.

Sie müssen sich wahrscheinlich keine Sorgen machen, da Sie die Benutzeroberfläche wahrscheinlich nur für sich selbst (oder vielleicht für einige Kollegen) codieren. Hier ist ein weiteres Beispiel, das Sinn machen könnte.

Wenn Sie ein öffentliches Array haben, z.

public int[] MyIntegers { get; }

Sie würden denken, dass, weil es nur einen "get" -Zugriff gibt, niemand mit den Werten herumspielen kann, aber das ist nicht wahr. Jeder kann die Werte dort einfach so ändern:

someObject.MyIngegers[3] = 12345;

Persönlich würde ich List<T>in den meisten Fällen nur verwenden . Wenn Sie jedoch eine Klassenbibliothek entwerfen, die Sie an zufällige Entwickler weitergeben möchten, und sich auf den Status der Objekte verlassen müssen, sollten Sie Ihre eigene Sammlung erstellen und von dort aus sperren: )

Es geht hauptsächlich darum, Ihre eigenen Implementierungen zu abstrahieren, anstatt das List-Objekt, das direkt bearbeitet werden soll, verfügbar zu machen.

Es ist keine gute Praxis, andere Objekte (oder Personen) den Status Ihrer Objekte direkt ändern zu lassen. Denken Sie an Getter / Setter.

Sammlung -> Für normale Sammlung
ReadOnlyCollection -> Für Sammlungen, die nicht geändert werden sollten
KeyedCollection -> Wenn Sie stattdessen Wörterbücher möchten.

Wie Sie das Problem beheben können, hängt davon ab, was Ihre Klasse tun soll und welchen Zweck die GetList () -Methode hat. Können Sie das näher erläutern?

In solchen Fällen versuche ich normalerweise, die geringste erforderliche Implementierungsmenge bereitzustellen. Wenn die Verbraucher nicht wissen müssen, dass Sie tatsächlich eine Liste verwenden, müssen Sie keine Liste zurückgeben. Wenn Sie zurückkehren, wie Microsoft eine Sammlung vorschlägt, verbergen Sie die Tatsache, dass Sie eine Liste verwenden, vor den Verbrauchern Ihrer Klasse und isolieren sie gegen eine interne Änderung.

Etwas hinzuzufügen, obwohl es lange her ist, dass dies gefragt wurde.

Wenn Ihr List<T>Listentyp von abgeleitet ist Collection<T>, können Sie die geschützten virtuellen Methoden, die Collection<T>implementiert werden, nicht implementieren. Dies bedeutet, dass der von Ihnen abgeleitete Typ nicht reagieren kann, wenn Änderungen an der Liste vorgenommen werden. Dies liegt daran, List<T>dass Sie wissen, wann Sie Elemente hinzufügen oder entfernen. In der Lage zu sein, auf Benachrichtigungen zu antworten, ist ein Aufwand und List<T>bietet ihn daher nicht an.

In Fällen, in denen externer Code Zugriff auf Ihre Sammlung hat, haben Sie möglicherweise keine Kontrolle darüber, wann ein Element hinzugefügt oder entfernt wird. Auf diese Collection<T>Weise können Sie feststellen, wann Ihre Liste geändert wurde.

Ich sehe kein Problem damit, so etwas zurückzugeben

this.InternalData.Filter(crteria).ToList();

Wenn ich eine nicht verbundene Kopie der internen Daten oder ein getrenntes Ergebnis einer Datenabfrage zurückgegeben habe, kann ich sicher zurückkehren, List<TItem>ohne Implementierungsdetails preiszugeben, und die zurückgegebenen Daten auf bequeme Weise verwenden.

Dies hängt jedoch davon ab, welche Art von Verbraucher ich erwarte - wenn es sich um ein Datenraster handelt, das ich lieber zurückgeben möchte IEnumerable<TItem> , wird dies in den meisten Fällen ohnehin die kopierte Liste der Artikel sein :)

Nun, die Collection-Klasse ist wirklich nur eine Wrapper-Klasse für andere Sammlungen, um deren Implementierungsdetails und andere Funktionen zu verbergen. Ich denke, dies hat etwas mit der Eigenschaft zu tun, die das Codierungsmuster in objektorientierten Sprachen verbirgt.

Ich denke, Sie sollten sich darüber keine Sorgen machen, aber wenn Sie dem Code-Analyse-Tool wirklich gefallen möchten, gehen Sie einfach wie folgt vor:

//using System.Collections.ObjectModel;

Collection<MyClass> myCollection = new Collection<MyClass>(myList);