Warum nicht generische ICollection implementieren IReadOnlyCollection in .NET 4.5?

In .NET 4.5 /C# 5, IReadOnlyCollection<T> wird deklariert mit einem Count Eigenschaft:

public interface IReadOnlyCollection<out T> : IEnumerable<T>, IEnumerable
{
    int Count { get; }
}

Frage ich mich, wäre es nicht sinnvoll für ICollection<T> zur Umsetzung der IReadOnlyCollection<T> - Schnittstelle als auch:

public interface ICollection<T> : IEnumerable<T>, IEnumerable, *IReadOnlyCollection<T>*

Diese habe gemeint, die Klassen der Umsetzung ICollection<T> haben, würde automatisch umgesetzt IReadOnlyCollection<T>. Das klingt mir vernünftig.

Den ICollection<T> Abstraktion betrachtet werden kann als eine Verlängerung der IReadOnlyCollection<T> Abstraktion. Beachten Sie, dass List<T>, zum Beispiel, implementiert sowohl ICollection<T> und IReadOnlyCollection<T>.

Aber es hat nicht so ausgelegt.

Was vermisse ich hier? Warum sollte der aktuellen Implementierung wurden stattdessen ausgewählt?


UPDATE

Ich bin auf der Suche nach einer Antwort, die verwendet objektorientierten design-Argumentation zu erklären, warum:

  • Eine konkrete Klasse, wie List<T> Umsetzung sowohl IReadOnlyCollection<T> und ICollection<T>

ist ein besseres design als:

  • ICollection<T> Umsetzung IReadOnlyCollection<T> direkt

Bitte beachten Sie auch, dass dies im Grunde die gleiche Frage wie:

  1. Warum nicht IList<T> implementieren IReadOnlyList<T>?
  2. Warum nicht IDictionary<T> implementieren IReadOnlyDictionary<T>?
  • Wie würde sich das auf die rückwärts-Kompatibilität?
  • ist es nicht so weit, wie ich sehen kann.. es sei denn, Sie liefern ein Gegenbeispiel?
  • Sie sind speziell beschlossen, um das brechen ändern, hinzufügen, die Lesen nur die entsprechenden Schnittstellen zu den Sammlungen .NET. (Wissend, dass die Fälle der tatsächlichen break-code sind eher künstlich und nicht wahrscheinlich zu sein weit verbreitet in der Produktion von code.)
  • Naja, auf technischer Ebene, so ziemlich alles ist eine wichtige änderung. Durch das hinzufügen einer neuen Schnittstelle, die es betreffen könnte Methode überlast Auflösung, zum Beispiel.
  • Ich bin noch nicht überzeugt, welche Seite hat das beste argument. Nachdem die Seiten gewechselt, mehrmals, jetzt Neige ich dazu zu neigen "ICollection<T> nicht implementieren sollte IReadOnlyCollection<T> und List<T> Umsetzung IReadOnlyList<T> macht keinen Sinn". Die größere Frage ist, wenn die Klasse C implementiert das interface I bedeutet das, dass C können I oder C sollte I. Finden Sie ein gleichwertiges Frage hier: why-does-listt-implement-ireadonlylistt-in-net-4-5. Zum nachdenken anregende Frage btw, +1!
  • Für statisch kompilierten code, überlast-Auflösung ist schon ein problem gelöst. Es gibt "targeting-packs" oder "reference assemblies", in denen nur die Typen in der framework-version, die Sie sind targeting. Der compiler erkennt diese und wird die überlast Auflösung die gleiche Weise, unabhängig davon, welche Laufzeit Ihr code ausgeführt wird, auf. Ihr Problem ist nur relevant, mit dynamischen code oder Reflexion, beide benötigen sorgfältig und sollte vermieden werden, wenn möglich, aus diesem und anderen Gründen. Immer anders Verhalten, wenn retargeting ist ein erwartet durch den Programmierer.
  • Ja, Wenn Sie als Ziel eine ältere .NET-runtime-Ihr code wird weiterhin funktionieren, sogar wenn der computer mit dem code hat eine neuere runtime. Die unterbrechende änderung, die ich meinte ist hier, dass, wenn Sie code kompiliert, sagen, .NET 3, dann ändern Sie die Laufzeit auf .NET 4.5, Sie können es nicht mehr kompilieren. Das ist eine wichtige änderung der Laufzeit änderung der Codebasis auf, dass die Laufzeit machen kann der code nicht mehr kompilieren.

InformationsquelleAutor Zaid Masud | 2012-09-27
Schreibe einen Kommentar