Pourquoi le tableau met en œuvre IList?

Voir la définition de Système.Tableau classe

public abstract class Array : IList, ...

Théoriquement, je devrais être capable d'écrire ce peu et être heureux

int[] list = new int[] {};
IList iList = (IList)list;

Je doit aussi être capable d'appeler n'importe quelle méthode de la iList

 ilist.Add(1); //exception here

Ma question n'est pas pourquoi j'obtiens une exception, mais plutôt pourquoi le Tableau met en œuvre IList?

  • Bon question. Je n'ai jamais aimé l'idée de la graisse interfaces (c'est le terme technique pour ce type de conception).
  • Le réel (mieux) la question serait pourquoi il prend en charge IList<T>. IList est l'héritage.
  • Comment pensez-vous qu'il rompt de substitution? Je pense qu'il ne l'est pas. Voir Brians réponse.
  • voir: blogs.msdn.com/b/bclteam/archive/2004/11/19/267089.aspx
  • Quelqu'un se soucient réellement de LSP? Il semble tout à fait académique pour moi.
  • ensuite, vous avez besoin de travailler avec de plus grandes bases de code. Mise en œuvre d'un comportement (héritant de l'interface) et puis tout simplement en ignorant les choses que vous n'aimez pas/ne peut pas soutenir conduit à malodorante, occulté, moulage et enfin: code bogué.
  • Vous devez mettre de la complexité quelque part. Disons que vous avez une méthode qui permet de trier un membre de sa catégorie. Avec un seul IList<> interface, vous pouvez vérifier IsReadOnly pour voir si vous pouvez les trier. Si vous avez séparé IRWList<> et IReadList<> interfaces, ce type de faire le membre de votre classe? Vous ne pouvez pas utiliser IRWList<> car alors il ne pouvait pas se tenir en lecture seule des objets, de sorte que vous avez à faire un IReadList<> et puis jeté à IRWList de faire votre tri. Voir -- malodorante, occulté casting.
  • son la collection qui implique la mutabilité pas ses entités qu'elle contient. Vous pouvez faire de votre membre de la classe d'un type qui implémente à la fois IRWList<>, et IReadList<>, utiliser si comme IRWList<> en interne dans votre classe et de l'exposer comme IReadList. Oui, vous avez à mettre de la complexité de quelque part, mais je ne vois pas comment cela s'applique à méconnaître LSP comme un très bon principe de conception (ne savaient pas au sujet de la propriété IsReadOnly bien que ce qui rend IList plus complexe à partir d'un point de vue des consommateurs)

InformationsquelleAutor oleksii | 2011-05-11
  1. 89

    Car un tableau permet un accès rapide à l'index, et IList/IList<T> est la seule collection d'interfaces qui prennent en charge cette. Alors peut-être votre vraie question est "Pourquoi il n'y a pas d'interface pour les constantes des collections avec des indexeurs?" Et à qui je n'ai pas de réponse.

    Il n'y a pas readonly interfaces pour les collections soit. Et il me manque encore plus qu'une constante de taille moyenne avec des indexeurs de l'interface.

    De l'OMI, il devrait y avoir plusieurs (générique) interfaces de collection en fonction des caractéristiques d'une collection. Et les noms ont été différent aussi, List pour quelque chose avec un indexeur est vraiment stupide de l'OMI.

    • Juste Énumération IEnumerable<T>
    • Readonly, mais pas de l'indexeur (.Le comte, .Contient,...)
    • Redimensionnable, mais pas de l'indexeur, c'est à dire définir comme (Ajouter, Supprimer,...) en cours ICollection<T>
    • Readonly avec indexation (indexation, indexof,...)
    • Taille constante avec d'indexation (indexation avec un setter)
    • Taille Variable avec l'indexeur (Insertion,...) en cours IList<T>

    Je pense que la collection actuelle interfaces sont de mauvaise conception. Mais depuis qu'ils ont des propriétés de vous dire les méthodes qui sont valables(et cela fait partie du contrat de ces méthodes) il ne rompt pas le principe de substitution.

    • merci pour la réponse. Mais je préfère laisser la question est. La raison en est simple. L'Interface est un contrat public. Si l'on met en œuvre, on doit mettre pleinement en œuvre tous les membres, sinon il se casse LSP et généralement sent mauvais, n'est-il pas?
    • Mais il n'y a pas de bonne alternative à IList<T> atm puisque c'est la seule interface de collecte avec un indexeur. Et tout le code qui a besoin d'un indexeur utilise donc IList<T>, en particulier, de nombreuses méthodes linq faire(Sauter,ElementAt,Arrière,...)
    • Il ne casse LSP. Si elle n'a pas de liste.Add(item) devrait ajouter un élément à la liste, quel que soit le type de béton. Sauf cas exceptionnelle. Dans la matrice de mise en œuvre en jette sur une exception de non-exceptionnelle cas, ce qui en soi est une mauvaise pratique
    • Est-il un core+bibliothèque dans une langue qui n'a d'obtenir les collections de droit? J'ai remarqué que l'auteur(s) de Clojure ont mis beaucoup de pensée dans la fabrication de choses cohérentes, mais Clojure est une tout autre plate-forme.
    • Voir blogs.msdn.com/b/andrewarnottms/archive/2011/08/22/...
    • il ne rompt pas LSP, vous êtes tout simplement à l'aide de ce mal. Vous devriez vérifier IsFixedSize ou IsReadOnly avant de tenter de la mutation de l'objet.
    • Je suis désolé, mais tu dois le LSP de mal là. Un tableau ne permet pas de mettre en œuvre add et ne peut donc pas être remplacé par quelque chose qui ne quand cette capacité est nécessaire.
    • Je concède que c' techniquement ne viole pas LSP seulement parce que de la documentation, vous devez vérifier la IsFixedSize et IsReadOnly propriétés, il a certainement viole le Dire, de Ne pas Poser de principe et Principe de moindre surprise. Pourquoi mettre en place une interface lorsque vous êtes juste de lancer des exceptions pour 4 des 9 méthodes?
    • Un certain temps s'est écoulé depuis que la question d'origine. Mais maintenant avec .Net 4.5, il existe d'autres interfaces IReadOnlyList et IReadOnlyCollection.
    • Très simplement, cela a été fait pour éviter de casser les changements de personnes se plaignent beaucoup plus clairement que cela.
    • il ne fait pas de sauts de LSP si vous cochez IsReadonly ou IsFixedSize mais il violer Ouvrir/Fermer. vérifier LSP ici stackoverflow.com/questions/4428725/...

    InformationsquelleAutor CodesInChaos
  2. 38

    La section "remarques" de la la documentation pour IList dit

    IList est un descendant de l'
    Interface ICollection et est la base
    l'interface de tous les non-générique listes.
    IList implémentations de l'automne en trois
    catégories: lecture seule, de taille fixe, et
    de taille variable,    . Lecture seule IList
    ne peut pas être modifié. Une taille fixe IList
    ne pas permettre l'ajout ou le retrait
    d'éléments, mais il permet à l'
    modification d'éléments existants. Un
    de taille variable, IList permet à l'
    l'ajout, la suppression et la modification de
    éléments.

    Évidemment tableaux de tomber dans la catégorie de taille, de sorte que par la defition de l'interface, cela fait sens.

    • Je suppose qu'ils se seraient retrouvés avec beaucoup d'interfaces. IListFixedSize, IListReadOnly...
    • qui a fait une bonne réponse à partir de la documentation du point de vue. Mais pour moi, cela s'apparente plutôt à un hack. Les Interfaces doivent être mince et simple pour une classe à mettre en œuvre tous les membres.
    • Je suis d'accord. Les Interfaces et les exceptions d'exécution ne sont pas les plus élégants de la combinaison. Dans la défense de Array il n'mettre en œuvre les Add méthode explicitement, ce qui réduit le risque de l'appeler par accident.
    • Jusqu'à ce que nous créons une mise en œuvre de IList qui interdit toute modification et ajout/suppression. Ensuite, la documentation n'est plus correct. 😛
    • Dans .Net 4.5, il existe d'autres interfaces IReadOnlyList et IReadOnlyCollection.
    InformationsquelleAutor Brian Rasmussen
  3. 17

    Parce que pas tous ILists sont mutables (voir IList.IsFixedSize et IList.IsReadOnly), et les tableaux certainement se comporter comme de taille fixe les listes.

    Si votre question est "pourquoi faut-il mettre en œuvre une non générique interface", alors la réponse est qu'elles étaient là avant les génériques sont venus le long.

    • Non, elle ne casse pas LSP, car l'interface IList lui-même vous dit qu'il ne peut pas être sujette au changement. Si c'était en fait la garantie d'être mutable et le tableau dit autrement, puis il serait briser la règle.
    • En fait, la Matrice de ne casser des LSP en cas de générique IList<T> et de ne pas le casser en cas de non-générique IList: enterprisecraftsmanship.com/2014/11/22/...
    InformationsquelleAutor Mehrdad
  4. 4

    C'est un héritage que nous avons de l'époque où c'était pas clair comment traiter avec lecture seule des collections et de la nécessité ou pas de Tableau est en lecture seule. Il y a IsFixedSize et IsReadOnly drapeaux dans l'interface IList. IsReadOnly indicateur signifie que la collecte ne peut pas être modifié à tous et IsFixedSize signifie que la collection d'autoriser la modification, mais pas de l'ajout ou la suppression d'éléments.

    Au moment de la .Net 4.5, il était clair que certains des "intermédiaires" interfaces sont nécessaires pour travailler avec lire seulement les collections, afin IReadOnlyCollection<T> et IReadOnlyList<T> ont été introduit.

    Voici un excellent billet de blog décrivant les détails: Lecture seule collections .NET

    InformationsquelleAutor Vladimir
  5. 0

    Définition de l'interface IList est "Représente un non-générique collection d'objets qui peuvent être individuellement accessibles par l'index.". Tableau complètement satisfait à cette définition, il doit implémenter l'interface.
    Exception lors de l'appel de méthode Add() est "le Système de.NotSupportedException: la Collecte a été de taille fixe" et a eu lieu parce que la matrice ne peut pas augmenter sa capacité de façon dynamique. Sa capacité est définie lors de la création de l'objet array.

    InformationsquelleAutor meir