Pourquoi List.Sort () est-il une méthode d’instance mais Array.Sort () statique?

Question

J'essaie de comprendre la décision de conception derrière cette partie du langage. J'admets que je suis très novice dans ce domaine, mais c'est quelque chose qui m'a tout de suite surpris et je me demandais s'il me manquait une raison évidente. Considérons le code suivant:

 List<int> MyList = new List<int>() { 5, 4, 3, 2, 1 };
int[] MyArray = {5,4,3,2,1};


//Sort the list
MyList.Sort();
//This was an instance method


//Sort the Array
Array.Sort(MyArray);
//This was a static method
 

Pourquoi ne sont-ils pas tous les deux mis en œuvre de la même manière - intuitivement, cela aurait plus de sens s'ils étaient tous deux des méthodes d'instance?

Answer 1

La question est intéressante, car elle révèle les détails de l' .NET type de système. Comme les types de valeur, chaîne et délégué des types, des types tableau recevez un traitement spécial .NET. Le plus notable oddish problème est que vous n'avez jamais explicitement déclarer un tableau de type. Le compilateur prend en charge pour vous, avec de larges portions de la gigue. Système.Tableau est un type abstrait, vous serez dédié types de tableau dans le processus de l'écriture de code. Soit en créant explicitement un type[] ou en utilisant des classes génériques qui ont un tableau dans leur base de mise en œuvre.

Dans un largish programme, d'avoir des centaines de types de tableau n'est pas inhabituel. Ce qui est correct, mais il n'y a que les coûts pour chaque type. C'est un service de stockage requis pour le type, et non pas les objets d'elle. Le plus gros morceau est le soi-disant "méthode de la table". En un mot, c'est une liste de pointeurs vers chaque méthode d'instance du type. À la fois le chargeur de classe et la gigue de travailler ensemble pour remplir ce tableau. Ceci est communément connu comme le 'v-table", mais ce n'est pas un match, le tableau contient des pointeurs vers des méthodes qui sont à la fois non-virtuel et virtuel.

Vous pouvez voir où cela mène peut-être, les designers ont été inquiet d'avoir beaucoup de types avec de grandes tables de méthodes. Donc cherché des moyens de réduire les frais généraux.

Tableau.Sort() est une cible évidente.

La même question n'est pas pertinente pour les types génériques. Une grande finesse de génériques, l'un des nombreux, une table de méthode peut gérer la méthode des pointeurs pour tout type de paramètre d'un type de référence.

Answer 2

La comparaison de deux types différents de "conteneurs d'objets d'':

MyList est une collection générique de type Liste, une classe wrapper, de type int, où l' List<T> représente une fortement typé liste d'objets. La Liste de la classe elle-même fournit des méthodes de recherche, de tri, et de manipuler ses objets contenus.

MyArray est une structure de base de données de type Tableau. Le Tableau n'est pas la même richesse de l'ensemble des méthodes de la Liste. Les tableaux peuvent en même temps être unidimensionnelles et multidimensionnelles ou déchiquetés, tandis que la liste de la boîte que sont unidimensionnelles.

Jetez un oeil à cette question, il offre une riche discussion sur ces types de données: Array versus List<T>: When to use which?

Answer 3

Sans demander à quelqu'un qui a été impliqué dans la conception de la plate-forme d'origine, il est difficile de savoir. Mais, voici ma conjecture.

Dans les anciennes langues, comme en C, les tableaux sont muets, des structures de données qu'ils n'ont pas de code de leur propre. Au lieu de cela, ils sont manipulés par l'extérieur méthodes. Comme vous vous déplacez dans un framework orienté Objet, le plus proche équivalent est un muet objet (avec un minimum de méthodes) manipulés par des méthodes statiques.

Donc, je suppose que la mise en œuvre de l' .NET de Tableaux est un symptôme de C style de pensée dans les premiers jours de son développement qu'autre chose.

Answer 4

Cela a probablement à voir avec l'héritage. Le Tableau de la classe ne peut pas être manuellement dérivés. Mais bizarrement, vous pouvez déclarer un tableau de n'importe quoi, et obtenir une instance de Système.Tableau qui est fortement typé, avant même les génériques vous a permis d'avoir des collections fortement typées. Tableau semble être l'un de ceux de la magie des pièces de la charpente.

Notez également qu'aucun de ces méthodes fournies sur un tableau massivement modifier le tableau. SetValue() semble être la seule qui change quoi que ce soit. Le Tableau de la classe elle-même fournit de nombreuses méthodes statiques qui permettent de modifier le contenu du tableau, comme Reverse() et de Tri(). Vous ne savez pas si c'est important - peut-être que quelqu'un ici peut donner quelques explications pour expliquer pourquoi c'est le cas.

En revanche, List<T> (ce qui n'est pas dans la dans la 1.0 cadre jours) et des classes comme l' ArrayList (qui était à cette époque) sont juste de l'usine de classes sans signification particulière dans le cadre. Ils fournissent une commune .Sort() méthode d'instance, de sorte que lorsque vous avez hérité de ces classes, vous avez que les fonctionnalités ou pourrait le remplacer.

Cependant, ces types de méthodes de tri ont disparu de la vogue de toute façon que les méthodes d'extension comme Linq .OrderBy() style de tri sont devenus la prochaine évolution. Vous pouvez interroger et de trier des tableaux et des Listes et tout autre objet énumérable avec le même mécanisme de maintenant, ce qui est vraiment, vraiment sympa.

-- EDIT --

Les autres, plus cyniques réponse est peut être tout simplement - c'est la façon dont Java fait de sorte que Microsoft fait de la même manière dans la version 1.0 du cadre, car à l'époque, ils étaient occupés à jouer de rattrapage.

Answer 5

Une des raisons pourrait être que Array.Sort été conçu dans .NET 1.0, qui ne comportait pas de génériques.