[Source] . .NET L’histoire de l’interface de collecte en lecture seule

Puisque nous avons l’intention de fournir une implémentation par défaut pour le problème dont vous parlez avec Joe, plutôt que de fournir une interface, nous fournissons la classe de base ReadOnlyCollectionBase. Cependant, je comprends pourquoi certaines personnes hésitent à l’utiliser car ce n’est pas un type fort. Mais avec l’introduction des génériques, nous avons désormais aussi <T>ReadOnlyCollection, ce qui vous permet non seulement d’avoir la même fonctionnalité, mais aussi un type puissant : super !

Puisque <T>ReadOnlyCollection n’est pas une classe scellée, vous pouvez écrire votre propre collection à pleine vitesse si nécessaire. Parce que ces collections que nous avons créées pour cela sont adaptables aux besoins généraux, nous ne prévoyons pas d’introduire des interfaces pour ce même concept.

Que cela puisse paraître surprenant ou non, IList et IList <T>sont les deux interfaces que nous avons l’intention d’utiliser pour les collections en lecture seule. Ils possèdent tous deux la propriété booléenne IsReadOnly, qui devrait être vraie lorsqu’une collection en lecture seule implémente cette propriété. La raison pour laquelle nous ne voulons pas ajouter une interface purement en lecture seule est que nous pensons que cela ajoute trop de complexité inutile à la bibliothèque de base. Notez qu’en termes de complexité, nous faisons référence à la fois à cette nouvelle interface et à ses utilisateurs.

Nous pensons que si le concepteur d’API ne se soucie pas de vérifier la propriété IsReadOnly à l’exécution et les exceptions qu’elle pourrait créer, alors il est acceptable d’utiliser l’interface IList dans ce cas ; S’ils sont prêts à fournir une API personnalisée vraiment propre d’un coup, alors dans ce cas, ils devraient montrer l’implémentation de l’interface IList et publier une API en lecture seule sur mesure. Cette dernière est typique des collections extraites du modèle d’objets.

La raison pour laquelle cela fonctionne, c’est que ces interfaces en lecture seule sont de purs sous-ensembles d’interfaces de lecture-écriture, ce qui semble être une hypothèse raisonnable. Malheureusement, cette hypothèse ne correspond pas à la réalité, car chaque méthode sur chaque interface au niveau des métadonnées possède son propre emplacement (ce qui permet à des implémentations d’interfaces explicites de fonctionner).

Nous avons envisagé ce design, mais nous avons estimé qu’ajouter un type ne fournissant que l’attribut Count n’apporterait pas beaucoup de valeur à la bibliothèque de base. Dans l’équipe de la bibliothèque de base, nous pensons que si une API commence à moins 1000, alors même fournir une certaine valeur ne suffit pas à justifier d’être ajoutée. La raison d’ajouter de nouvelles API inclut également un coût, par exemple les développeurs auront plus de concepts parmi lesquels choisir. Au début, nous pensions qu’ajouter ce type rendrait le code meilleur performant dans certains scénarios où l’on veut juste obtenir un compte puis faire quelque chose d’intéressant avec. Par exemple, ajouter en bloc à une collection existante. Cependant, dans ces scénarios, nous avons encouragé les gens à n’utiliser que l’interface IEnumerable<T>, et <T>dans le cas particulier d’avoir une instance qui implémente l’interface ICollection. Puisque tous nos types de collections intégrés implémentent cette interface, il n’y a eu aucun gain de performance dans ces scénarios les plus courants. Au fait, <T>la méthode d’extension Count() pour IEnumerable peut aussi faire cela.