Это хорошая практика для создания ClassCollection другого класса?

Допустим, у меня есть Carкласс:

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

Допустим, мы создаем систему для парковки, я собираюсь использовать много Carклассов, поэтому мы создаем CarCollectionкласс, который может иметь несколько дополнительных методов, таких как FindCarByModel:

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

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

Если я учусь на уроке ParkingLot, что лучше?

Опция 1:

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

Вариант № 2:

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

Это даже хорошая практика для создания ClassCollectionдругого Class?

До появления дженериков в .NET была обычная практика создания «типизированных» коллекций, чтобы вы могли иметь и class CarCollectionт. Д. Для каждого типа, который нужно сгруппировать. В .NET 2.0 с введением Generics появился новый класс, List<T>который избавляет вас от необходимости создавать и CarCollectionт. Д., Которые вы можете создать List<Car>.

В большинстве случаев вы обнаружите, что этого List<T>достаточно для ваших целей, однако могут быть случаи, когда вы хотите иметь конкретное поведение в своей коллекции, если вы считаете, что это так, у вас есть несколько вариантов:

• Создайте класс, который инкапсулирует, List<T>например,public class CarCollection { private List<Car> cars = new List<Car>(); public void Add(Car car) { this.cars.Add(car); }}
• Создать собственную коллекцию public class CarCollection : CollectionBase<Car> {}

Если вы используете подход инкапсуляции, вы должны как минимум выставить перечислитель, чтобы объявить его следующим образом:

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

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

Без этого вы не сможете перезаписать foreachколлекцию.

Некоторые причины, по которым вы можете захотеть создать собственную коллекцию:

• Вы не хотите полностью раскрывать все методы IList<T>илиICollection<T>
• Вы хотите выполнить дополнительные действия при добавлении или удалении элемента из коллекции

Это хорошая практика? хорошо, это зависит от того, почему вы это делаете, если это, например, одна из причин, которые я перечислил выше, тогда да.

Microsoft делает это довольно регулярно, вот несколько сравнительно недавних примеров:

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

Что касается ваших FindByметодов, я хотел бы поместить их в методы расширения, чтобы их можно было использовать для любой коллекции, содержащей автомобили:

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

    ...
}

Это отделяет задачу запроса коллекции от класса, в котором хранятся автомобили.

Нет. Создание XXXCollectionклассов в значительной степени вышло из моды с появлением обобщений в .NET 2.0. На самом деле, есть замечательное Cast<T>()расширение LINQ, которое люди используют в наши дни для извлечения материала из этих пользовательских форматов.

Часто бывает удобно иметь доменно-ориентированные методы для поиска / нарезки коллекций, как в примере FindByCarModel выше, но нет необходимости прибегать к созданию классов коллекций-оболочек. В этой ситуации сейчас я обычно создаю набор методов расширения.

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

Вы добавляете так много фильтров или полезных методов к этому классу , как вам нравится, и вы можете использовать их везде, где есть IEnumerable<Car>, что включает в себя все ICollection<Car>, массивы Car, и IList<Car>т.д.

Поскольку у нашего решения для персистентности есть поставщик LINQ, я также часто создаю похожие методы фильтрации, которые работают и возвращают IQueryable<T>, поэтому мы можем применить эти операции и к хранилищу.

Идиома .NET (ну, C #) сильно изменилась с 1.1. Поддержание пользовательских классов коллекций - это боль, и вы мало выигрываете от наследования, CollectionBase<T>поскольку вы не получаете решения с помощью метода расширений, если все, что вам нужно, - это специфичные для домена методы фильтрации и селектора.

Я думаю, что единственной причиной создания специального класса для хранения коллекции других элементов должно быть то, что вы добавляете в него что-то ценное, нечто большее, чем просто инкапсуляция / наследование от экземпляра IListили другого типа коллекции.

Например, в вашем случае добавление функции, которая будет возвращать списки автомобилей, припаркованных на четных / неровных участках ... И даже тогда ... возможно, только если это часто используется повторно, потому что если он занимает только одну строку с хорошим LinQ функция и используется только один раз, какой смысл? ПОЦЕЛУЙ !

Теперь, если вы планируете предлагать много методов сортировки / поиска, тогда да, я думаю, что это может быть полезно, потому что это то, где они должны принадлежать, в этом специальном классе коллекции. Это также хороший способ «скрыть» сложности некоторых запросов «найти» или всего, что вы могли бы сделать в методе сортировки / поиска.

Я предпочитаю использовать следующую опцию, чтобы вы могли добавить свой метод в коллекцию и использовать преимущество списка.

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

и тогда вы можете использовать его как C # 7.0

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

Или вы можете использовать его как

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

- Общая версия благодаря комментарию @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
     }

и тогда вы можете использовать его

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
}