1. Zuhause
  2. Frage und Antwort
  3. Warum wird es als schlecht angesehen, die Liste <T> freizulegen?

Warum wird es als schlecht angesehen, die Liste <T> freizulegen?

2008-12-23 5 views

Antwort

48

Ich stimme Elch-im-Dschungel hier zu: List<T> ist ein unbeschränktes, aufgeblähtes Objekt, das viel "Gepäck" darin hat.

Zum Glück ist die Lösung einfach: expose IList<T> stattdessen.

Es stellt eine Barebone-Schnittstelle, die die meisten alle List<T> ‚s Methoden hat (mit Ausnahme von Dingen wie AddRange()), und es ist nicht auf den spezifischen List<T> Typ beschränken, die Ihre API Verbraucher können ihre eigenen verwenden Implementierer von IList<T>.

Für noch mehr Flexibilität sollten Sie erwägen, einige Sammlungen gegebenenfalls IEnumerable<T> auszusetzen.

Quelle

2008-12-23 02:04:35

+0

Was würden Sie für einen Web-Service empfehlen (wo eine Methode keine Schnittstelle zurückgeben/aufnehmen kann)? – kpollock

+1

kpollock - leider SOAP Web-Dienste * wird * jede IList in ein Array des Typs T [] -> Serialisierung unterstützt nicht die generische Listentyp. –

+6

Nur weil Sie IList verwenden, bedeutet das nicht, dass Sie Speicher sparen, wenn Sie das bekommen. Sie instanziieren es mit der neuen Liste (), und die Variable IList zeigt weiterhin auf eine Liste im Speicher. Abgesehen davon denke ich, dass es normalerweise vorteilhaft ist, eine Sammlung zu kapseln, anstatt sie direkt dem Client-Code auszusetzen. – jlafay

3

Ich glaube, Sie wollen nicht Ihre Kunden neue Elemente in Ihrer Rückkehr hinzufügen. Eine API sollte klar und vollständig sein und wenn sie ein Array zurückgibt, sollte sie die genaue Datenstruktur zurückgeben. Ich glaube nicht, dass es etwas mit T pro sagen zu tun, sondern eher eine Liste <> anstelle eines Arrays Rückkehr [] direkt

Quelle

2008-12-23 01:46:17 leora

+4

-1. Insbesondere sollte [Eigenschaften keine Arrays zurückgeben] (http://msdn.microsoft.com/en-us/library/0fss9skc%28v=VS.100%29.aspx). Während Methoden in allgemeinen Sammlungen, aufzählbaren Sequenzen und Schnittstellen für C# idiomatischer sind. – TrueWill

25

Es sind die zwei Hauptgründe:

  • Liste <T> ist ein eher aufgeblähter Typ mit vielen Mitgliedern, die in vielen Szenarien nicht relevant sind (ist für öffentliche Objektmodelle zu "beschäftigt").
  • Die Klasse ist nicht abgedichtet, aber nicht speziell erweitert werden entworfen (Sie keine Mitglieder außer Kraft setzen können)

Quelle

2008-12-23 01:53:34 edgi

+7

Genau richtig.Hier ist ein Link zu Krzysztof Cwalina zum Thema: http://blogs.msdn.com/kcwalina/archive/2005/09/26/474010.aspx –

5

Es ist nur eine schlechte Praxis in Betracht gezogen, wenn Sie eine API schreiben, die von Tausenden oder Millionen von Entwicklern verwendet werden.

Das .NET-Framework-Design-Richtlinien sind für Microsofts öffentlichen APIs gemeint.

Wenn Sie eine API haben, die nicht von vielen Personen verwendet wird, sollten Sie die Warnung ignorieren.

Quelle

2008-12-23 01:57:33

+0

Sie wissen schon ... ich war einfach nur da falsch ... Ich aktualisiere meine Antwort. –

+0

Nun ... dann werde ich meinen Kommentar entfernen, der nicht mehr relevant ist. :) –

+2

Obwohl es stimmt, dass einige der FxCop-Regeln Framework-Design-Richtlinien sind und für einige Projekte möglicherweise nicht geeignet sind, können sogar Bibliotheken, die für kleine Teams entwickelt wurden, davon profitieren, sie zu befolgen. Haben Sie jemals 5 Entwicklern gesagt, dass sie ihre Projekte ändern müssen, weil Sie eine bahnbrechende Änderung an einer Bibliothek vornehmen müssen (sagen wir, um Änderungen zu beobachten, wie @Kaagle erwähnt)? Haben Entwickler in Ihrem Team jemals etwas getan, was Sie nicht erwartet haben, wie zum Beispiel den Inhalt einer Listeneigenschaft, die Sie nur lesen möchten? – TrueWill

2

Ein Grund dafür ist, weil Liste nicht etwas ist, können Sie simulieren. Selbst in weniger populären Bibliotheken habe ich Wiederholungen gesehen, die aufgrund dieser Empfehlung ein List-Objekt als IList verfügbar machten, und in späteren Versionen entschieden, die Daten überhaupt nicht in einer Liste zu speichern (vielleicht in einer Datenbank). Da es sich um eine IList handelte, war es keine bahnbrechende Änderung, die Implementierung unter den Clients zu ändern und trotzdem alle zu arbeiten.

Quelle

2008-12-23 03:57:21

2

Einer der Gründe ist, dass der Benutzer in der Lage sein wird, die Liste zu ändern, und der Besitzer der Liste nicht darüber Bescheid weiß, während er in einigen Fällen einige Dinge nach dem Hinzufügen/Entfernen von Elementen aus der Liste tun muss. Auch wenn es jetzt nicht benötigt wird, kann es in Zukunft zur Anforderung werden. Also ist es besser, dem Besitzer der Klasse die AddXXX/RemoveXXX-Methode hinzuzufügen und die Liste und IEnumerable oder (was meiner Meinung nach besser ist) als eine IList verfügbar zu machen und ObservableCollection von WindowsBase zu verwenden.

Quelle

2008-12-23 12:27:19

+1

Enthüllung 'List ' als 'IList ' oder 'IEnumerable ' schützt nicht gegen den Benutzer Änderung der Liste (nach einer Besetzung im Falle von IEnumerable '). Wenn Sie eine unveränderbare Liste zurückgeben möchten, geben Sie 'ReadOnlyCollection ' zurück oder verwenden Sie IEnumerable .AsReadOnly() ', das als' IList 'zurückgegeben werden kann. – Joe

 Verwandte Themen

  • Keine verwandten Themen^_^