È una buona pratica creare un ClassCollection di un'altra classe?

Diciamo che ho una Carlezione:

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

Diciamo che stiamo creando un sistema per un parcheggio, userò molta della Carclasse, quindi creiamo una CarCollectionclasse, potrebbe avere alcuni metodi di aditionals come FindCarByModel:

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

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

Se sto facendo una lezione ParkingLot, qual è la migliore pratica?

Opzione 1:

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

Opzione 2:

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

È anche una buona pratica creare un ClassCollectionaltro Class?

Prima dei generici in .NET, era pratica comune creare raccolte "tipizzate" in modo da avere class CarCollectionecc per ogni tipo che era necessario raggruppare. In .NET 2.0 con l'introduzione di Generics, è List<T>stata introdotta una nuova classe che ti consente di evitare di creare CarCollectionecc List<Car>.

La maggior parte delle volte, scoprirai che List<T>è sufficiente per i tuoi scopi, tuttavia ci possono essere momenti in cui desideri avere un comportamento specifico nella tua raccolta, se ritieni che sia così, hai un paio di opzioni:

• Crea una classe che incapsula List<T>per esempiopublic class CarCollection { private List<Car> cars = new List<Car>(); public void Add(Car car) { this.cars.Add(car); }}
• Crea una raccolta personalizzata public class CarCollection : CollectionBase<Car> {}

Se scegli l'approccio di incapsulamento, dovresti esporre almeno l'enumeratore in modo da dichiararlo come segue:

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

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

Senza farlo, non puoi fare un foreachover the collection.

Alcuni motivi per cui potresti voler creare una raccolta personalizzata sono:

• Non vuoi esporre completamente tutti i metodi in IList<T>oICollection<T>
• Desideri eseguire azioni aggiuntive dopo aver aggiunto o rimosso un elemento dalla raccolta

È buona pratica? bene dipende dal motivo per cui lo stai facendo, se è per esempio uno dei motivi che ho elencato sopra, allora sì.

Microsoft lo fa abbastanza regolarmente, ecco alcuni esempi abbastanza recenti:

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

Per quanto riguarda i tuoi FindBymetodi, sarei tentato di metterli in metodi di estensione in modo che possano essere utilizzati contro qualsiasi raccolta contenente automobili:

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

    ...
}

Ciò separa la preoccupazione di interrogare la collezione dalla classe che immagazzina le auto.

No. La creazione di XXXCollectionclassi praticamente è passata di moda con l'avvento dei generici in .NET 2.0. In effetti, esiste Cast<T>()un'elegante estensione LINQ che la gente usa in questi giorni per ottenere cose da quei formati personalizzati.

È spesso utile disporre di metodi orientati al dominio per trovare / suddividere le raccolte, come nell'esempio FindByCarModel sopra, ma non è necessario ricorrere alla creazione di classi di raccolte wrapper. In questa situazione, ora in genere creerò una serie di metodi di estensione.

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

Aggiungete tutti i metodi di filtro o utilità a quella classe che volete e potete usarli ovunque possiate IEnumerable<Car>, che include qualsiasi cosa ICollection<Car>, array di Car, IList<Car>ecc.

Poiché la nostra soluzione di persistenza ha un provider LINQ, spesso creerò anche metodi di filtro simili che funzionano e ritornano IQueryable<T>, in modo da poter applicare queste operazioni anche al repository.

Il linguaggio di .NET (beh, C #) è cambiato molto dall'1.1. Mantenere le classi di raccolta personalizzate è una seccatura e dall'eredità CollectionBase<T>non si guadagna molto che non si ottiene con la soluzione del metodo di estensione se tutto ciò di cui si ha bisogno sono i filtri specifici del dominio e i metodi di selezione.

Penso che l'unico motivo per creare una classe speciale per contenere una raccolta di altri elementi debba essere quando aggiungi qualcosa di valore ad essa, qualcosa di più che semplicemente incapsulare / ereditare da un'istanza di IListo un altro tipo di raccolta.

Ad esempio, nel tuo caso, aggiungendo una funzione che restituirebbe elenchi di auto parcheggiate su spazi di lotto pari / irregolari ... E anche allora ... forse solo se viene spesso riutilizzato, perché se prende solo una riga con un bel LinQ funzione e viene utilizzata una sola volta, qual è il punto? BACIO !

Ora, se hai intenzione di offrire molti metodi di ordinamento / ricerca, allora sì, penso che potrebbe essere utile perché è lì che dovrebbero appartenere, in quella speciale classe di raccolta. Questo è anche un buon modo per "nascondere" la complessità di alcune query "trova" o qualunque cosa tu possa fare in un metodo di ordinamento / ricerca.

Preferisco andare con la seguente opzione, quindi puoi aggiungere il tuo metodo alla raccolta e usare il vantaggio dell'elenco.

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

e quindi puoi usarlo come C # 7.0

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

Oppure puoi usarlo come

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

- Versione generica grazie al commento di @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
     }

e poi puoi 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
}