Warum nicht Readonlycollection <> gehören Methoden wie FindAll (), Findfirst (),

Question

Im Anschluss an die Vorschläge von FxCop und meine persönliche Neigung Ich habe das Team ermutigend ich Coaching ReadOnlyCollections so viel möglich zu nutzen. Wenn nur so, dass der Empfänger der Listen kann nicht ihren Inhalt ändern. In ihrer Theorie ist dieses Brot & Butter. Das Problem ist, dass die List <> Schnittstelle ist viel reicher, alle Arten von nützlichen Methoden auszusetzen. Warum haben sie machen diese Wahl?

Geben Sie einfach auf und beschreibbaren Sammlungen zurückkehren? Haben Sie Nur-Lese-Sammlungen zurückkehren und sie dann in der beschreibbaren Vielfalt wickeln? Ahhhhh.

---

Update: Dank Ich bin vertraut mit dem Rahmendesignrichtlinien und das ist, warum das Team FxCop nutzt es zu erzwingen. Aber dieses Team lebt mit VS 2005 (ich weiß, ich weiß) und so sage ihnen, dass LINQ / Erweiterung Methoden, um ihre Probleme zu lösen, würde nur macht sie traurig.

Sie haben gelernt, dass List.FindAll () und .FindFirst () eine größere Klarheit als eine foreach-Schleife zu schreiben. Jetzt sie ich drängen ReadOnlyCollections verwenden sie verlieren diese Klarheit.

Vielleicht gibt es ein tieferes Design-Problem, das ich nicht Spek.

- leider der Original-Beitrag sollte die VS2005 Einschränkung erwähnt hat. Ich habe so lange mit gelebt, dass ich einfach nicht bemerken.

Answer 1

Abschnitt 8.3.2 des .NET Framework-Entwurf Richtlinien Second Edition :

  

Verwendung ReadOnlyCollection<T>, eine Unterklasse von ReadOnlyCollection<T>, oder in seltenen Fällen IEnumerable<T> Objekte oder Rückgabewerte darstellen, schreibgeschützte Sammlungen.

Wir gehen mit ReadOnlyCollections unsere Absicht der Sammlung zurück zum Ausdruck bringen.

Die List<T> Methoden, die Sie sprechen von versetzt .NET 2.0 für die Bequemlichkeit in. In C # 3.0 / .NET 3.5, können Sie all diese Methoden wieder auf ReadOnlyCollection<T> bekommen (oder jeden IEnumerable<T>) Erweiterungsmethoden verwenden (und LINQ-Operatoren als auch verwenden), so dass ich glaube nicht, dass sie jede Motivation ist für das Hinzufügen von nativ auf andere Typen . Die Tatsache, dass sie überhaupt auf Liste existiert nur eine historische Note aufgrund der Anwesenheit von Erweiterungsmethoden verfügbar sein, aber waren nicht in 2.0.

Answer 2

Zunächst einmal, tut ReadOnlyCollection<T> IEnumerable<T> und IList<T> implementieren. Mit all den Erweiterungsmethoden in .NET 3.5 und LINQ, haben Sie Zugriff auf fast alle Funktionen von der ursprünglichen List<T> Klasse in Bezug auf die Abfrage-, die alles, was Sie mit einem ReadOnlyCollection<T> sowieso tun sollten.

aber sagen, dass Ihre erste Frage führt mich einige Vorschläge zu machen ...

Rückkehr List<T> ist schlechtes Design, so dass es kein Vergleichspunkt sein sollte. List<T> sollte für die Umsetzung verwendet werden, aber für die Schnittstelle sollte IList<T> zurückgegeben werden. Der Framework Design Guidelines speziell Zustand:

" NICHT Verwendung ArrayList oder List<T> in öffentlichen APIs." (Seite 251)

Wenn Sie dies berücksichtigen, gibt es absolut keinen Nachteil ReadOnlyCollection<T> wenn zu List<T> verglichen. Beide dieser Klassen implementieren IEnumerable<T> und IList<T>, das sind die Schnittstellen, die sowieso zurückgegeben werden sollen.

Answer 3

Ich habe keinen Einblick, warum sie nicht ursprünglich hinzugefügt wurden. Aber jetzt, wo wir LINQ habe ich sicherlich sehen keinen Grund, sie von der Sprache, in zukünftigen Versionen hinzufügen. Die Methoden, die Sie leicht erwähnt können in einer LINQ-Abfrage heute geschrieben werden. In diesen Tagen benutze ich nur die LINQ-Abfragen für so ziemlich alles. Ich mehr bekommen tatsächlich oft verärgert über List<T> diese Methoden haben, weil es mit Erweiterungsmethoden in Konflikt I gegen IEnumerable<T> schreiben.

Answer 4

Ich denke, Jeffs Antwort irgendwie enthält die Antwort, die Sie benötigen; statt ReadOnlyCollection<T>, geben eine Unterklasse davon ... eine, die Sie selbst implementieren die Methoden enthalten, die Sie ohne ein Upgrade auf VS2008 / LINQ verwenden möchten.