¿Es una buena práctica crear una ClassCollection de otra clase?

Vamos a decir que tengo una Carclase:

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

Digamos que estamos haciendo un sistema sobre un estacionamiento, voy a usar una gran parte de la Carclase, por lo que hacemos una CarCollectionclase, puede tener algunos métodos adicionales como FindCarByModel:

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

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

Si estoy haciendo una clase ParkingLot, ¿cuál es la mejor práctica?

Opción 1:

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

Opcion 2:

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

¿Es incluso una buena práctica crear uno ClassCollectionde otro Class?

Antes de los genéricos en .NET, era una práctica común crear colecciones 'escritas' para que tuviera class CarCollectionetc. para cada tipo que necesitara agrupar. En .NET 2.0 con la introducción de Generics, List<T>se introdujo una nueva clase que le ahorra tener que crear, CarCollectionetc., como puede crear List<Car>.

La mayoría de las veces, encontrará que List<T>es suficiente para sus propósitos, sin embargo, puede haber ocasiones en que desee tener un comportamiento específico en su colección, si cree que este es el caso, tiene un par de opciones:

• Crear una clase que encapsule List<T>por ejemplopublic class CarCollection { private List<Car> cars = new List<Car>(); public void Add(Car car) { this.cars.Add(car); }}
• Crea una colección personalizada public class CarCollection : CollectionBase<Car> {}

Si opta por el enfoque de encapsulación, como mínimo debe exponer el enumerador para que lo declare de la siguiente manera:

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

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

Sin hacer eso, no puedes hacer una foreachsobre la colección.

Algunas razones por las que puede querer crear una colección personalizada son:

• No desea exponer completamente todos los métodos en IList<T>oICollection<T>
• Desea realizar acciones adicionales al agregar o eliminar un elemento de la colección

¿Es una buena práctica? bueno, eso depende de por qué lo está haciendo, si es, por ejemplo, una de las razones que he enumerado anteriormente, entonces sí.

Microsoft lo hace con bastante regularidad, aquí hay algunos ejemplos bastante recientes:

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

En cuanto a sus FindBymétodos, estaría tentado de ponerlos en métodos de extensión para que puedan usarse contra cualquier colección que contenga automóviles:

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

    ...
}

Esto separa la preocupación de consultar la colección de la clase que almacena los autos.

No. La creación de XXXCollectionclases pasó de moda con la llegada de los genéricos en .NET 2.0. De hecho, existe la ingeniosa Cast<T>()extensión LINQ que la gente usa actualmente para sacar cosas de esos formatos personalizados.

A menudo es útil tener métodos orientados al dominio para buscar / dividir colecciones, como en el ejemplo de FindByCarModel anterior, pero no hay necesidad de recurrir a la creación de clases de colección de contenedor. En esta situación, normalmente crearé un conjunto de métodos de extensión.

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

Agrega tantos filtros o métodos de utilidad a esa clase como desee, y puede usarlos en cualquier lugar que tenga IEnumerable<Car>, lo que incluye cualquier cosa ICollection<Car>, matrices Car, IList<Car>etc.

Dado que nuestra solución de persistencia tiene un proveedor LINQ, con frecuencia también crearé métodos de filtro similares que operan y regresan IQueryable<T>, para que también podamos aplicar estas operaciones al repositorio.

El idioma de .NET (bueno, C #) ha cambiado mucho desde 1.1. Mantener clases de colección personalizadas es una molestia, y gana poco al heredar de CollectionBase<T>lo que no obtiene con la solución del método de extensión si todo lo que necesita es un filtro específico de dominio y métodos de selección.

Creo que la única razón para crear una clase especial para mantener una colección de otros elementos debería ser cuando se le agrega algo de valor, algo más que simplemente encapsular / heredar de una instancia IListu otro tipo de colección.

Por ejemplo, en su caso, agregue una función que devolvería sublistas de automóviles estacionados en espacios de lotes pares / desiguales ... E incluso entonces ... tal vez solo si se reutiliza a menudo, porque si solo toma una línea con un bonito LinQ funciona y se usa solo una vez, ¿cuál es el punto? BESO !

Ahora, si planea ofrecer muchos métodos de clasificación / búsqueda, entonces sí, creo que esto podría ser útil porque aquí es donde deberían pertenecer, en esa clase de colección especial. Esta también es una buena manera de "ocultar" las complejidades de algunas consultas de "búsqueda" o cualquier cosa que pueda hacer en un método de clasificación / búsqueda.

Prefiero ir con la siguiente opción, para que pueda agregar su método a la colección y usar la ventaja de la lista.

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

y luego puedes usarlo como C # 7.0

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

O puedes usarlo como

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

- Versión genérica gracias al comentario de @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
     }

y luego puedes usarlo

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
}