Est-ce une bonne pratique de créer une classe de classe d'une autre classe?

Disons que j'ai un Carcours:

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

Disons que nous construisons un système sur un parking, je vais utiliser beaucoup de Carcours, alors nous faisons un CarCollectioncours, il peut avoir quelques méthodes supplémentaires telles que FindCarByModel:

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

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

Si je fais un cours ParkingLot, quelle est la meilleure pratique?

Option 1:

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

Option 2:

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

Est-ce même une bonne pratique de créer un ClassCollectionautre Class?

Avant les génériques dans .NET, il était courant de créer des collections 'dactylographiées' afin que vous ayez class CarCollectionetc pour chaque type que vous aviez besoin de grouper. Dans .NET 2.0, avec l'introduction de Generics, une nouvelle classe a List<T>été introduite, ce qui vous évite d'avoir à créer CarCollectionetc. comme vous pouvez le créer List<Car>.

La plupart du temps, vous constaterez que cela List<T>suffit pour vos besoins, mais il peut arriver que vous souhaitiez avoir un comportement spécifique dans votre collection. Si vous pensez que cela est le cas, vous avez plusieurs options:

• Créez une classe qui encapsule List<T>par exemplepublic class CarCollection { private List<Car> cars = new List<Car>(); public void Add(Car car) { this.cars.Add(car); }}
• Créer une collection personnalisée public class CarCollection : CollectionBase<Car> {}

Si vous optez pour l’encapsulation, vous devez au moins exposer l’énumérateur afin de le déclarer comme suit:

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

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

Sans cela, vous ne pouvez pas en faire foreachplus sur la collection.

Certaines des raisons pour lesquelles vous pouvez créer une collection personnalisée sont les suivantes:

• Vous ne voulez pas exposer complètement toutes les méthodes IList<T>ouICollection<T>
• Vous souhaitez effectuer des actions supplémentaires lors de l'ajout ou de la suppression d'un élément de la collection

Est-ce une bonne pratique? Cela dépend de la raison pour laquelle vous le faites. Si c’est par exemple l’une des raisons que j’ai énumérées ci-dessus, alors oui.

Microsoft le fait assez régulièrement, voici quelques exemples assez récents:

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

En ce qui concerne vos FindByméthodes, je serais tenté de les mettre en extension afin qu’elles puissent être utilisées contre toute collection contenant des voitures:

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

    ...
}

Ceci sépare le souci d'interroger la collection de la classe qui stocke les voitures.

Non. La création de XXXCollectionclasses est tombée en désuétude avec l'avènement des génériques dans .NET 2.0. En fait, il existe l' Cast<T>()extension astucieuse LINQ que les gens utilisent de nos jours pour extraire des contenus de ces formats personnalisés.

Il est souvent pratique de disposer de méthodes orientées domaine pour rechercher / découper des collections, comme dans l'exemple de FindByCarModel ci-dessus, mais il n'est pas nécessaire de recourir à la création de classes de collection wrapper. Dans cette situation, je vais maintenant généralement créer un ensemble de méthodes d'extension.

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

Vous ajoutez autant de méthodes de filtrage ou d’utilitaires à cette classe que vous le souhaitez, et vous pouvez les utiliser n’importe où vous avez IEnumerable<Car>, y compris tout type de ICollection<Car>tableaux Car, IList<Car>etc.

Étant donné que notre solution de persistance a un fournisseur LINQ, je crée fréquemment des méthodes de filtrage similaires qui fonctionnent sur et qui renvoient IQueryable<T>afin que nous puissions également appliquer ces opérations au référentiel.

L'idiome de .NET (enfin, C #) a beaucoup changé depuis la 1.1. La maintenance de classes de collection personnalisées est une tâche ardue, et vous n’avez que peu à gagner en héritant de CollectionBase<T>la solution de méthode d’extension si vous n’avez besoin que de méthodes de filtre et de sélecteur spécifiques à un domaine.

Je pense que la seule raison de créer une classe spéciale pour la conservation d'une collection d'autres éléments doit être ajoutée lorsque vous ajoutez quelque chose de valeur, autre chose que simplement encapsuler / hériter d'une instance IListou d'un autre type de collection.

Par exemple, dans votre cas, ajouter une fonction qui renverrait des sous-listes de voitures garées sur des espaces de lots pairs / irréguliers ... fonction et est utilisé qu'une seule fois, quel est le point? KISS !

Maintenant, si vous envisagez d’offrir beaucoup de méthodes de tri / recherche, alors oui, je pense que cela pourrait être utile car c’est là qu’elles devraient appartenir, dans cette classe de collection spéciale. C'est également un bon moyen de "masquer" la complexité de certaines requêtes "trouver" ou de tout ce que vous pouvez faire avec une méthode de tri / recherche.

Je préfère utiliser l'option suivante pour pouvoir ajouter votre méthode à la collection et utiliser l'avantage de la liste.

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

et alors vous pouvez l'utiliser comme C # 7.0

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

Ou vous pouvez l'utiliser comme

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

- Version générique grâce au commentaire @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
     }

et alors vous pouvez l'utiliser

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
}