Collection <T> a List <T>, czego należy używać w swoich interfejsach?

Kod wygląda jak poniżej:

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

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

Po uruchomieniu analizy kodu otrzymuję następujące zalecenie.

Ostrzeżenie 3 CA1002: Microsoft.Design: Zmień 'List' w 'IMyClass.GetList ()', aby użyć Collection, ReadOnlyCollection lub KeyedCollection

Jak mam to naprawić i jakie są tutaj dobre praktyki?

Aby odpowiedzieć na pytanie „dlaczego”, dlaczego nie List<T> , powody są przyszłościowe i prostota API.

Gotowość na przyszłość

List<T>nie jest zaprojektowany tak, aby można go było łatwo rozszerzać poprzez tworzenie podklas; został zaprojektowany tak, aby był szybki we wdrożeniach wewnętrznych. Zauważysz, że metody na nim nie są wirtualne i dlatego nie można ich zastąpić, i nie ma żadnych punktów zaczepienia w jego operacjach Add/ Insert/ Remove.

Oznacza to, że jeśli będziesz musiał zmienić zachowanie kolekcji w przyszłości (np. Aby odrzucić obiekty puste, które ludzie próbują dodać, lub wykonać dodatkową pracę, gdy tak się stanie, np. Zaktualizować stan twojej klasy), musisz zmienić typ kolekcji, wrócisz do takiej, którą możesz podklasować, co będzie zepsutą zmianą interfejsu (oczywiście zmiana semantyki rzeczy, takich jak niedopuszczanie do wartości null, może być również zmianą interfejsu, ale rzeczy takie jak aktualizacja wewnętrznego stanu klasy nie byłyby).

Dlatego zwracając klasę, którą można łatwo podzielić na podklasę, taką jak Collection<T>lub interfejs, taki jak IList<T>, ICollection<T>lub IEnumerable<T>możesz zmienić wewnętrzną implementację, aby była innym typem kolekcji, aby spełnić Twoje potrzeby, bez łamania kodu konsumentów, ponieważ nadal można ją zwrócić jako rodzaj, jakiego oczekują.

Prostota interfejsu API

List<T>zawiera wiele przydatnych funkcji, takich jak BinarySearch, Sorti tak dalej. Jednak jeśli jest to kolekcja, którą ujawniasz, prawdopodobnie kontrolujesz semantykę listy, a nie konsumentów. Więc chociaż twoja klasa wewnętrznie może potrzebować tych operacji, jest bardzo mało prawdopodobne, że konsumenci twojej klasy będą chcieli (lub nawet powinni) je wywoływać.

W związku z tym, oferując prostszą klasę kolekcji lub interfejs, zmniejszasz liczbę członków, których widzą użytkownicy Twojego interfejsu API, i ułatwiasz im korzystanie.

Osobiście zadeklarowałbym, że zwraca interfejs, a nie konkretną kolekcję. Jeśli naprawdę chcesz mieć dostęp do listy, użyj IList<T>. W przeciwnym razie rozważ ICollection<T>i IEnumerable<T>.

Chyba nikt jeszcze nie odpowiedział na część „dlaczego” ... więc proszę bardzo. Powodem, dla którego "powinieneś" używać a Collection<T>zamiast a, List<T>jest to, że jeśli ujawnisz a List<T>, to każdy, kto uzyska dostęp do twojego obiektu, będzie mógł modyfikować elementy na liście. Natomiast Collection<T>ma wskazywać, że tworzysz własne metody „Dodaj”, „Usuń” itp.

Prawdopodobnie nie musisz się tym martwić, ponieważ prawdopodobnie kodujesz interfejs tylko dla siebie (lub może kilku kolegów). Oto kolejny przykład, który może mieć sens.

Jeśli masz publiczną tablicę, np:

public int[] MyIntegers { get; }

Można by pomyśleć, że ponieważ jest tylko akcesor „get”, którego nikt nie może zepsuć wartości, ale to nieprawda. Każdy może zmienić wartości w środku, tak jak to:

someObject.MyIngegers[3] = 12345;

Osobiście po prostu używałbym List<T>w większości przypadków. Ale jeśli projektujesz bibliotekę klas, którą zamierzasz rozdać przypadkowym programistom i musisz polegać na stanie obiektów ... wtedy będziesz chciał stworzyć własną kolekcję i zablokować ją stamtąd: )

Chodzi głównie o wyabstrahowanie własnych implementacji zamiast ujawniania obiektu List do bezpośredniej manipulacji.

Nie jest dobrą praktyką pozwalanie innym obiektom (lub ludziom) bezpośrednio modyfikować stan twoich obiektów. Pomyśl o metodach pobierających / ustawiających właściwości.

Kolekcja -> Dla zwykłej kolekcji
ReadOnlyCollection -> Dla kolekcji, które nie powinny być modyfikowane
KeyedCollection -> Gdy chcesz zamiast tego słowniki.

Sposób rozwiązania tego problemu zależy od tego, co ma robić Twoja klasa i od celu metody GetList (). Czy możesz rozwinąć?

W tego rodzaju przypadkach zwykle staram się ujawnić jak najmniejszą ilość implementacji, jaka jest potrzebna. Jeśli konsumenci nie muszą wiedzieć, że faktycznie używasz listy, nie musisz jej zwracać. Wracając zgodnie z sugestią firmy Microsoft dotyczącą kolekcji, ukrywasz fakt, że używasz listy przed użytkownikami swojej klasy i izolujesz ich przed wewnętrzną zmianą.

Coś do dodania, chociaż minęło dużo czasu, odkąd o to zapytano.

Gdy typ listy pochodzi od List<T>zamiast Collection<T>, nie można zaimplementować chronionych metod wirtualnych, które Collection<T>implementują. Oznacza to, że typ pochodny nie może odpowiedzieć w przypadku wprowadzenia jakichkolwiek modyfikacji na liście. Dzieje się tak, ponieważ List<T>zakłada się, że wiesz, kiedy dodajesz lub usuwasz elementy. Możliwość odpowiadania na powiadomienia to narzut i dlatego List<T>go nie oferuje.

W przypadkach, gdy kod zewnętrzny ma dostęp do Twojej kolekcji, możesz nie mieć kontroli nad dodawaniem lub usuwaniem elementu. Dlatego Collection<T>zapewnia sposób sprawdzenia, kiedy lista została zmodyfikowana.

Nie widzę problemu ze zwrotem czegoś takiego

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

Jeśli zwróciłem odłączoną kopię danych wewnętrznych, albo odpisałem wynik zapytania o dane - mogę bezpiecznie wrócić List<TItem>bez ujawniania szczegółów implementacji i pozwolić na wygodne wykorzystanie zwróconych danych.

Ale to zależy od tego, jakiego rodzaju konsumenta oczekuję - jeśli jest to coś w rodzaju siatki danych, wolę zwrócić, IEnumerable<TItem> która i tak będzie skopiowaną listą pozycji w większości przypadków :)

Cóż, klasa Collection jest po prostu klasą opakowującą wokół innych kolekcji, aby ukryć szczegóły ich implementacji i inne funkcje. Myślę, że ma to coś wspólnego z właściwościami ukrywającymi wzorzec kodowania w językach zorientowanych obiektowo.

Myślę, że nie powinieneś się tym martwić, ale jeśli naprawdę chcesz zadowolić narzędzie do analizy kodu, wykonaj następujące czynności:

//using System.Collections.ObjectModel;

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