Czy dobrą praktyką jest utworzenie kolekcji innej klasy?

Powiedzmy, że mam Carklasę:

public class Car
{
    public string Engine { get; set; }
    public string Seat { get; set; }
    public string Tires { get; set; }
}

Powiedzmy, że tworzymy system o parkingu, zamierzam wykorzystać dużo Carklasy, więc tworzymy CarCollectionklasę, może mieć kilka dodatkowych metod, takich jak FindCarByModel:

public class CarCollection
{
    public List<Car> Cars { get; set; }

    public Car FindCarByModel(string model)
    {
        // code here
        return new Car();
    }
}

Jeśli robię zajęcia ParkingLot, jaka jest najlepsza praktyka?

Opcja 1:

public class ParkingLot
{
    public List<Car> Cars { get; set; }
    //some other properties
}

Opcja 2:

public class ParkingLot
{
    public CarCollection Cars { get; set; }
    //some other properties
}

Czy to dobra praktyka, aby stworzyć ClassCollectioninną Class?

Przed generycznymi w .NET powszechną praktyką było tworzenie kolekcji „na maszynie”, aby mieć class CarCollectionitd. Dla każdego typu, który trzeba pogrupować. W .NET 2.0 z wprowadzeniem Generics wprowadzono nową klasę, List<T>która oszczędza konieczności tworzenia CarCollectionitp. Podczas tworzenia List<Car>.

List<T>Przez większość czasu okaże się, że jest to wystarczające do realizacji twoich celów, jednak może się zdarzyć, że będziesz chciał mieć określone zachowanie w swojej kolekcji, jeśli uważasz, że tak jest, masz kilka opcji:

• Utwórz List<T>na przykład klasę, która będzie hermetyzowaćpublic class CarCollection { private List<Car> cars = new List<Car>(); public void Add(Car car) { this.cars.Add(car); }}
• Utwórz własną kolekcję public class CarCollection : CollectionBase<Car> {}

Jeśli wybierzesz metodę enkapsulacji, powinieneś przynajmniej odsłonić moduł wyliczający, aby zadeklarować go w następujący sposób:

public class CarCollection : IEnumerable<Car>
{
    private List<Car> cars = new List<Car>();

    public IEnumerator<Car> GetEnumerator() { return this.cars.GetEnumerator(); }
}

Bez tego nie można przerobić foreachkolekcji.

Niektóre powody, dla których warto utworzyć kolekcję niestandardową, to:

• Nie chcesz w pełni ujawniać wszystkich metod w IList<T>lubICollection<T>
• Chcesz wykonać dodatkowe czynności po dodaniu lub usunięciu elementu z kolekcji

Czy to dobra praktyka? cóż, to zależy od tego , dlaczego to robisz, jeśli jest to na przykład jeden z powodów, które wymieniłem powyżej, to tak.

Microsoft robi to dość regularnie, oto kilka całkiem nowych przykładów:

• System.Web.Http.Filters.HttpFilterCollection
• System.Web.Mvc.ModelBinderProviderCollection

Jeśli chodzi o twoje FindBymetody, pokusiłbym się o zastosowanie ich w metodach rozszerzenia, aby można było ich używać przeciwko dowolnej kolekcji zawierającej samochody:

public static class CarLookupQueries
{
    public static Car FindByLicencePlate(this IEnumerable<Car> source, string licencePlate)
    {
        return source.SingleOrDefault(c => c.LicencePlate == licencePlate);
    }

    ...
}

Oddziela to kwestię zapytania kolekcji od klasy, która przechowuje samochody.

Nie. Tworzenie XXXCollectionklas praktycznie przestało być modne wraz z pojawieniem się generics w .NET 2.0. W rzeczywistości istnieje fajne Cast<T>()rozszerzenie LINQ, którego ludzie używają w dzisiejszych czasach, aby wydobyć rzeczy z tych niestandardowych formatów.

Często przydatne są metody zorientowane na domeny do znajdowania / wycinania kolekcji, jak w powyższym przykładzie FindByCarModel, ale nie ma potrzeby uciekania się do tworzenia klas kolekcji opakowań. W tej sytuacji zazwyczaj utworzę teraz zestaw metod rozszerzenia.

public static class CarExtensions
{
    public static IEnumerable<Car> ByModel(this IEnumerable<Car> cars, string model)
    {
        return cars.Where(car => car.Model == model);
    }
}

Dodać dowolną liczbę filtrów lub użyteczności metod do tej klasy, jak chcesz, i można z nich korzystać w dowolnym miejscu masz IEnumerable<Car>, który zawiera wszystko ICollection<Car>, tablice Car, IList<Car>etc.

Ponieważ nasze rozwiązanie utrwalające ma dostawcę LINQ, często tworzę również podobne metody filtrowania, które działają i zwracają IQueryable<T>, abyśmy mogli zastosować te operacje również w repozytorium.

Idiom .NET (cóż, C #) bardzo się zmienił od 1.1. Utrzymywanie niestandardowych klas kolekcji jest uciążliwe, a dziedziczenie CollectionBase<T>po nich nie przynosi korzyści , ponieważ nie dostajesz rozwiązania z metodą rozszerzenia, jeśli wszystko, czego potrzebujesz, to metody filtrowania i selekcji specyficzne dla domeny.

Myślę, że jedynym powodem, aby stworzyć specjalną klasę do przechowywania kolekcji innych przedmiotów, powinno być dodanie czegoś wartościowego, czegoś więcej niż tylko hermetyzacja / odziedziczenie po instancji IListlub innym typie kolekcji.

Na przykład, w twoim przypadku, dodanie funkcji, która zwróciłaby podlisty samochodów zaparkowanych na parzystych / nierównych powierzchniach działki ... I nawet wtedy ... może tylko wtedy, gdy często jest ponownie używana, ponieważ jeśli zajmuje tylko jedną linię z ładnym LinQ funkcja i jest używana tylko raz, o co chodzi? KISS !

Teraz, jeśli planujesz zaoferować wiele metod sortowania / wyszukiwania, to tak, myślę, że może to być przydatne, ponieważ właśnie tam powinny one należeć, w tej specjalnej klasie kolekcji. Jest to również dobry sposób na „ukrycie” złożoności niektórych zapytań „znajdź” lub cokolwiek innego, co można zrobić w metodzie sortowania / wyszukiwania.

Wolę iść z następującą opcją, abyś mógł dodać swoją metodę do kolekcji i skorzystać z zalet listy.

public class CarCollection:List<Car>
{
    public Car FindCarByModel(string model)
    {
        // code here
        return new Car();
    }
}

a następnie możesz użyć go jak w C # 7.0

public class ParkingLot
{
    public CarCollection Cars { get; set; }=new CarCollection();
    //some other properties
}

Lub możesz go użyć jak

public class ParkingLot
{
   public ParkingLot()
   {
      //initial set
      Cars =new CarCollection();
   }
    public CarCollection Cars { get; set; }
    //some other properties
}

- Ogólna wersja dzięki komentarzowi @Bryan

   public class MyCollection<T>:List<T> where T:class,new()
    {
        public T FindOrNew(Predicate<T> predicate)
        {
            // code here
            return Find(predicate)?? new T();
        }
       //Other Common methods
     }

i wtedy możesz go użyć

public class ParkingLot
{
    public MyCollection<Car> Cars { get; set; }=new MyCollection<Car>();
    public MyCollection<Motor> Motors{ get; set; }=new MyCollection<Motor>();
    public MyCollection<Bike> Bikes{ get; set; }=new MyCollection<Bike>();
    //some other properties
}