Warum nicht von List & lt; T & gt;

Gibt es einige gute Antworten hier. Ich würde hinzufügen, um Sie, die folgenden Punkte.

Was ist die richtige C# Möglichkeit der Darstellung einer Datenstruktur, die "logisch" ist (das heißt, "den menschlichen Geist") ist nur eine Liste der Dinge, die mit ein paar Glocken und Pfeifen?

Bitten alle zehn nicht-computer-Programmierer, Leute, die vertraut sind mit der Existenz des Fußballs, füllen Sie die leeren:

A football team is a particular kind of _____

Haben jemand sagen Sie "Liste der Fußball-Spieler mit ein paar Glocken und Pfeifen", oder haben Sie alle sagen "Sport-team" oder "Verein" oder "Organisation"? Ihre Vorstellung, dass eine Fußball-Mannschaft eine Besondere Art von Liste der Spieler ist in Ihrem menschlichen Geist und den menschlichen Geist allein.

List<T> ist ein Mechanismus. Fußball-team ist eine business-Objekt -- das heißt, ein Objekt, das bedeutet das Konzept, dass in der business domain des Programms. Don ' T mix! Ein Fußball-team ist eine Art team; es hat eine Dienstplan, Dienstplan ist eine Liste der Spieler, die. Ein Dienstplan ist kein Besondere Art von Liste der Spieler. Ein Dienstplan ist eine Liste von Spielern. So stellen Sie eine Eigenschaft namens Roster ist ein List<Player>. Und machen es ReadOnlyList<Player> während Sie gerade dabei sind, es sei denn, Sie glauben, dass jeder, kennt ein Fußball-team bekommt zu löschen-Spieler aus dem Dienstplan.

Erbt von List<T> immer inakzeptabel?

Nicht akzeptabel für wen? Mich? Nein.

Wann ist es akzeptabel?

Wenn Sie bauen einen Mechanismus, der erweitert die List<T> Mechanismus.

Was muss ein Programmierer betrachten, bei der Entscheidung, ob Erben von List<T> oder nicht?

Bin ich bauen ein Mechanismus oder eine business-Objekt?

Aber das ist eine ganze Menge code! Was bekomme ich für alle, dass die Arbeit?

Sie verbrachte mehr Zeit die Eingabe Ihrer Frage, die Sie sich genommen haben Sie zu schreiben forwarding-Methoden für die jeweiligen Mitglieder der List<T> fünfzig mal vorbei. Du hast eindeutig keine Angst vor Ausführlichkeit, und wir reden über eine sehr kleine Menge von Programmcode hier; dies ist ein paar Minuten Arbeit.

UPDATE

Gab ich es ein paar mehr Gedanken und es ist ein weiterer Grund, nicht Modell, ein Fußball-team als eine Liste von Spielern. Es wäre In der Tat eine schlechte Idee, Modell, ein Fußball-team als mit eine Liste von Spielern zu. Das problem mit team/mit einer Liste der Spieler ist, dass was du hast ist ein snapshot des Teams an einen moment in der Zeit. Ich weiß nicht, was der business case ist für diese Klasse, aber wenn ich hatte eine Klasse, die vertreten, ein Fußball-team ich würde mir wünschen, bitten, es Fragen wie "wie viele Seahawks-Spieler verpasste Spiele aufgrund einer Verletzung zwischen 2003 und 2013?" oder "Was Denver Spieler, der zuvor für ein anderes team gespielt hatte, das größte Jahr-über-Jahr Zunahme yards ran?" oder "Habe die Piggers den ganzen Weg gehen in diesem Jahr?"

Ist, ein Fußball-team scheint mir gut zu sein modelliert als eine Sammlung von historischen Fakten wie wenn ein Spieler rekrutiert wurde, verletzt, Rentner usw. Offensichtlich ist die aktuelle Spieler-Kader ist eine wichtige Tatsache, dass sollte wohl front-und-center, aber es können auch andere interessante Dinge, die Sie tun möchten, mit diesem Objekt, Bedarf es einer historischen Perspektive.

InformationsquelleAutor der Antwort Eric Lippert

Wow, dein post hat eine ganze Reihe von Fragen und Punkten. Die meisten der Argumentation, die Sie von Microsoft erhalten, ist genau auf dem Punkt. Beginnen wir mit alles über List<T>

• List<T> ist stark optimiert. Die eigentliche Verwendung ist der Einsatz als private member eines Objekts.
• Microsoft nicht verschließen, weil manchmal möchten Sie möglicherweise erstellen Sie eine Klasse, die einen freundlicheren Namen: class MyList<T, TX> : List<CustomObject<T, Something<TX>> { ... }. Jetzt ist es so einfach wie zu tun var list = new MyList<int, string>();.
• CA1002: setzen Sie nicht generischen Listen: Im Grunde, auch wenn Sie planen, verwenden Sie diese app als einziger Entwickler, lohnt es, sich zu entwickeln, gute programmierpraktiken, so werden Sie eingeflößt in Ihnen und zweite Natur. Sie sind immer noch erlaubt, verfügbar zu machen, die Liste als eine IList<T> wenn Sie alle Verbraucher haben eine indizierte Liste. Dies können Sie ändern Sie die Implementierung innerhalb einer Klasse später auf.
• Microsoft gemacht Collection<T> sehr generisch, weil es sich um ein generisches Konzept... der name sagt alles; es ist nur eine Sammlung. Es sind präziser Versionen wie SortedCollection<T>, ObservableCollection<T>, ReadOnlyCollection<T> usw. jeder der die Umsetzung IList<T> aber nicht List<T>.
• Collection<T> ermöglicht für die Mitglieder (d.h. Hinzufügen, Entfernen, etc.) außer Kraft gesetzt werden, weil Sie virtuell sind. List<T> nicht.
• Der Letzte Teil Ihrer Frage ist vor Ort auf. Ein Fußball-team ist mehr als nur eine Liste von Spielern, so sollte es sein, eine Klasse, die enthält die Liste der Spieler. Denke Komposition vs. Vererbung. Ein Fußball-team hat eine Liste der Spieler (a-Kader), ist es nicht eine Liste von Spielern.

Wenn ich das schreiben würde die Klasse wohl Aussehen so:

public class FootballTeam
{
    //Football team rosters are generally 53 total players.
    private readonly List<T> _roster = new List<T>(53);

    public IList<T> Roster
    {
        get { return _roster; }
    }

    //Yes. I used LINQ here. This is so I don't have to worry about
    //_roster.Length vs _roster.Count vs anything else.
    public int PlayerCount
    {
        get { return _roster.Count(); }
    }

    //Any additional members you want to expose/wrap.
}

InformationsquelleAutor der Antwort m-y

Dies ist ein klassisches Beispiel von Zusammensetzung vs Vererbung.

In diesem konkreten Fall:

Ist das team eine Liste von Spielern mit zusätzlichen Verhalten

oder

Ist das team ein Objekt seiner eigenen, die geschieht, um eine Liste der Spieler.

Durch die Ausweitung der Liste, die Sie begrenzen sich selbst in eine Anzahl von Möglichkeiten:

1. Können Sie nicht beschränken Sie den Zugriff (für Beispiel, stoppen Menschen ändern Dienstplan). Erhalten Sie die Liste der Methoden, ob Sie brauchen/wollen oder nicht.

2. Was passiert, wenn Sie haben wollen Listen andere Dinge auch. Zum Beispiel, teams haben Trainer, Manager, fans, Ausrüstung, etc. Einige von denen könnte gut sein, Listen in Ihrem eigenen Recht.

3. Begrenzen Sie Ihre Optionen für die Vererbung. Zum Beispiel möchten Sie möglicherweise erstellen Sie eine generische Team Objekt -, und dann haben BaseballTeam, FootballTeam, etc. Erben, die. Erben aus der Liste müssen Sie die Vererbung vom Team, aber das bedeutet dann, dass alle die verschiedenen Arten von team gezwungen sind, die gleiche Implementierung der Dienstplan.

Zusammensetzung - einschließlich ein Objekt geben, das Verhalten, das Sie wollen, in Ihrem Objekt.

Vererbung - Ihr Objekt wird zu einer Instanz des Objekts, das Verhalten, das Sie möchten.

Beide haben Ihren nutzen, aber das ist ein klarer Fall, wo die Komposition ist vorzuziehen.

InformationsquelleAutor der Antwort Tim B

Was ist, wenn die FootballTeam hat eine Reserven-team zusammen mit den wichtigsten team?

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
}

Wie würden Sie das Modell, das mit?

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}

Die Beziehung ist eindeutig hat eine und nicht ist ein.

oder RetiredPlayers?

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
    List<FootballPlayer> RetiredPlayers { get; set; }
}

Als eine Regel von Daumen, wenn Sie jemals wollen, um zu Erben aus einer Sammlung, name der Klasse SomethingCollection.

Macht Ihr SomethingCollection semantisch Sinn machen? Tun Sie dies nur, wenn Ihr Typ ist ein Sammlung von Something.

Im Fall von FootballTeam es klingt nicht richtig. Ein Team ist mehr als ein Collection. Ein Team haben kann, coaches, Trainer, etc, da die anderen Antworten haben darauf hingewiesen.

FootballCollection klingt wie eine Sammlung von Fußbälle oder vielleicht eine Sammlung von Fußball-Utensilien. TeamCollection eine Auflistung von teams.

FootballPlayerCollection klingt wie eine Auflistung der Spieler, welche würden Sie einen gültigen Namen für eine Klasse, die erbt von List<FootballPlayer> wenn Sie wirklich wollte, das zu tun.

Wirklich List<FootballPlayer> ist eine ganz gute Art zu behandeln. Vielleicht IList<FootballPlayer> wenn Sie die Rückkehr aus einer Methode.

Zusammenfassend

Fragen Sie sich

1. Ist X eine Y? oder Hat X eine Y?

2. Tun meiner Klasse Namen bedeuten, was Sie sind?

InformationsquelleAutor der Antwort Sam Leach

Design - > Umsetzung

Welche Methoden und Eigenschaften, die Sie setzen ist eine design-Entscheidung. Was Basisklasse Erben Sie von ist eine Implementierung detail. Ich fühle es sich lohnt, einen Schritt zurück zu den ehemaligen.

Ein Objekt ist eine Sammlung von Daten und Verhalten.

Damit Ihre ersten Fragen sollte sein:

• Welche Daten sind in diesem Objekt enthalten in dem Modell bin ich erstellen?
• Welches Verhalten hat dieses Objekt aufweisen in das Modell?
• Wie könnte sich dies in Zukunft ändern?

Bedenken, dass die Vererbung impliziert eine "isa" (ist eine) Beziehung, in der Erwägung, dass die Zusammensetzung impliziert eine "hat ein" (hasa) Beziehung. Wählen Sie die richtige für Ihre situation aus Ihrer Sicht, unter Berücksichtigung, wo die Dinge gehen könnte, wie Sie Ihre Anwendung entwickelt.

Berücksichtigen, denken in Schnittstellen, bevor Sie denken in Beton-Arten, wie einige Leute finden es einfacher, um Ihr Gehirn in den "design-Modus" Weg.

Dies ist nicht etwas, das jeder tut, bewusst auf dieser Ebene von Tag zu Tag Codierung. Aber wenn Sie über diese Art von Thema, du trittst in design-Gewässern. Es zu wissen kann befreiend sein.

Betrachten Design Besonderheiten

Werfen Sie einen Blick auf List<T> und IList<T> auf MSDN oder Visual Studio. Sehen Sie, welche Methoden und Eigenschaften, die Sie setzen. Diese Methoden alle etwas Aussehen jemand tun würde, um ein FootballTeam aus Ihrer Sicht?

Tut footballTeam.Reverse() Sinn? Tut footballTeam.ConvertAll<TOutput>() wie etwas Aussehen, was Sie wollen?

Dies ist nicht eine Fangfrage; die Antwort könnte wirklich sein "ja". Wenn Sie implementieren/inherit List<Spieler> oder IList<Spieler>, du steckst mit Ihnen, wenn das ist ideal für Ihr Modell, es zu tun.

Wenn Sie sich entscheiden, ja, das macht Sinn, und Sie wollen Ihr Objekt behandelt werden als eine Sammlung/Liste der Spieler (das Verhalten), und Sie wollen deshalb die ICollection implementieren oder IList, mit allen Mitteln tun. Notionally:

class FootballTeam : ... ICollection<Player>
{
    ...
}

Wenn Sie möchten, dass Ihr Objekt enthalten eine Sammlung/Liste der Spieler (- Daten), und Sie wollen deshalb die Sammlung oder Liste, um eine Eigenschaft oder-Mitglied, mit allen Mitteln tun. Notionally:

class FootballTeam ...
{
    public ICollection<Player> Players { get { ... } }
}

Könnte man glauben, dass Sie wollen, dass die Leute in der Lage sein, um nur die aufzuzählen, die Spieler, anstatt Sie zählen, um Sie hinzuzufügen oder Sie zu entfernen. IEnumerable<Player> ist eine durchaus Valide option zu prüfen.

Könnte man glauben, dass keines dieser interfaces sind nützlich in Ihrem Modell überhaupt. Dies ist weniger wahrscheinlich (IEnumerable<T> ist in vielen Situationen nützlich) aber es ist immer noch möglich.

Jemand, der versucht, Ihnen zu sagen, dass man von diesen ist es grundsätzlich und endgültig die falsch in jedem Fall ist falsch. Wer versucht, Ihnen zu sagen, es ist kategorisch und endgültig Recht in jedem Fall ist fehlgeleitet.

Bewegen sich auf die Umsetzung

Sobald Sie sich entschieden haben, auf Daten und das Verhalten, können Sie eine Entscheidung über die Umsetzung. Dies beinhaltet die konkreten Klassen abhängen, die über Vererbung oder Komposition.

Kann dies nicht ein großer Schritt sein, und die Menschen oft verschmelzen design und Implementierung, da es durchaus möglich ist, durch Sie laufen alle in Ihrem Kopf in ein oder zwei Sekunden und beginnen Sie mit der Eingabe entfernt.

Ein Gedankenexperiment

Einem künstlichen Beispiel: wie andere erwähnt haben, ein team ist nicht immer "nur" eine Ansammlung von Spielern. Pflegen Sie eine Auflistung der Punktestände für das team? Das team der austauschbar mit dem Verein, die Sie in Ihrem Modell? Wenn dem so ist, und wenn Ihr team der isa-Kollektion von Spielern, vielleicht ist es auch isa Erfassung von Personal und/oder eine Sammlung von Partituren. Dann sind Sie am Ende mit:

class FootballTeam : ... ICollection<Player>, 
                         ICollection<StaffMember>,
                         ICollection<Score>
{
    ....
}

Design trotz, an dieser Stelle in C# Sie nicht in der Lage sein, um alle diese, durch Erben von List<T> wie auch immer, da C# auch "nur" unterstützt einfache Vererbung. (Wenn Sie versucht haben, diese malarky in C++, können Sie halten dies für eine Gute Sache.) Durchführung einer Erhebung über die Vererbung und über die Zusammensetzung ist wahrscheinlich fühlen schmutzig. Und Eigenschaften wie Zählen, werden die Nutzer verwirrt, es sei denn, Sie implementieren ILIst<Player>.Zählen und IList<StaffMember>.Zählen etc. explizit, und dann sind Sie einfach nur schmerzhaft, eher als verwirrend. Sie können sehen, wo das hinführt; Bauchgefühl und dachte nach unten, diesen Weg kann auch Ihnen sagen, es fühlt sich falsch an Kopf in diese Richtung (und zu Recht oder zu Unrecht, Ihre Kollegen könnten, auch wenn Sie umgesetzt wird es auf diese Weise!)

Die Kurze Antwort (Zu Spät)

Die Richtlinie nicht Erben von collection-Klassen nicht C# spezifisch, finden Sie es in vielen Programmiersprachen. Sie empfangen die Weisheit nicht ein Gesetz. Ein Grund dafür ist, dass in der Praxis der Komposition betrachtet, ist zu oft gewinnen, die über die Vererbung in Bezug auf Verständlichkeit, implementability und Wartbarkeit. Es ist eher üblich mit der realen Welt /domain-Objekte zu finden, die sinnvoll und konsistent "hasa" - Beziehungen als sinnvoll und konsistent "isa" Beziehung, es sei denn, Sie sind tief in das abstrakte, die meisten vor allem, wie die Zeit vergeht und die genauen Daten und das Verhalten der Objekte in der code-änderungen. Dies sollte nicht dazu führen, dass Sie immer Regel die Erben von collection-Klassen; aber es kann suggestiv.

InformationsquelleAutor der Antwort El Zorko

Es hängt vom Kontext

Wenn Sie erwägen, Ihr team, wie eine Liste von Spielern, Sie sind die Projektion der "Idee" eines Fuß-ball-team bis zu einem Aspekt: Sie reduzieren das "team" um die Menschen, die Sie sehen auf dem Feld. Diese Projektion ist nur richtig, in einem bestimmten Kontext. In einem anderen Zusammenhang, könnte dies völlig falsch. Stellen Sie sich vor Sie möchten ein sponsor des Teams. So haben Sie zu sprechen, um die Manager des Teams. In diesem Zusammenhang wird die Mannschaft voraussichtlich in die Liste der Führungskräfte. Und diese beiden Listen in der Regel nicht überlappen sehr stark. In anderen Kontexten sind die aktuellen gegen die ehemalige Spieler, etc.

Unklare Semantik

Also das problem mit der Erwägung, ein team, eine Liste der Spieler, die in Ihrer semantischen, hängt von dem Kontext und, dass es nicht erweitert werden kann, wenn sich der Kontext ändert. Zusätzlich ist es schwer, zum Ausdruck zu bringen, in welchem Kontext Sie verwenden.

Klassen sind erweiterbar

Wenn Sie mit einer Klasse mit nur einem Mitglied (z.B. IList activePlayers), können Sie den Namen des Mitglieds (und zusätzlich seinen Kommentar), damit der Kontext klar. Wenn es gibt weitere Kontexte, fügen Sie einfach ein zusätzliches Mitglied.

- Klassen sind komplexer

In einigen Fällen ist es möglicherweise übertrieben, erstellen Sie eine zusätzliche Klasse. Jeder muss die Klassendefinition geladen werden durch den classloader und zwischengespeichert werden durch die virtuelle Maschine. Dies kostet Sie-runtime-Leistung und Speicher. Wenn Sie einen sehr spezifischen Kontext, es wäre OK, zu prüfen, ein Fußball-team als eine Liste von Spielern. Aber in diesem Fall sollte man wirklich nur verwenden IList , nicht eine Klasse daraus abgeleitet.

Schlussfolgerung /Überlegungen

Wenn Sie einen sehr spezifischen Kontext, es ist OK, betrachten Sie ein team als eine Liste von Spielern. Zum Beispiel innerhalb einer Methode ist es völlig OK zu schreiben

IList<Player> footballTeam = ...

Bei der Verwendung von F#, es kann sogar sein OK, um zu erstellen, eine Art Abkürzung

type FootballTeam = IList<Player>

Aber, wenn der Kontext breiter oder sogar unklar, Sie sollte das nicht tun. Dies ist insbesondere der Fall, wenn Sie eine neue Klasse erstellen, in denen nicht klar ist, in welchem Kontext es verwendet werden kann in der Zukunft. Ein Warnzeichen ist, wenn Sie beginnen, fügen Sie zusätzliche Attribute für die Klasse (Namen der Mannschaft, Trainer, usw.). Dies ist ein klares Zeichen, dass der Kontext, in dem die Klasse verwendet wird, ist nicht festgelegt und wird sich in Zukunft ändern. In diesem Fall können Sie überlegen, das team als eine Liste von Spielern, aber Sie sollten-Modell die Liste der (aktuell aktive, nicht verletzt, etc.) Spieler, die als ein Attribut der team.

InformationsquelleAutor der Antwort stefan.schwetschke

Macht es den Menschen ermöglicht, zu sagen

myTeam.subList(3, 5);

überhaupt Sinn? Wenn nicht, dann sollte es nicht eine Liste.

InformationsquelleAutor der Antwort Cruncher

Hängt es von der Verhalten Ihrer "team" - Objekt. Wenn es verhält sich genauso wie eine Sammlung, es wäre OK, zu vertreten, zunächst mit einer einfachen Liste. Dann könnten Sie beginnen zu bemerken, dass Sie halten das duplizieren von code, der wiederholt auf der Liste; an dieser Stelle haben Sie die Möglichkeit der Erstellung eines FootballTeam Objekt umschließt, die Liste der Spieler. Das FootballTeam der Klasse wird das Basisverzeichnis für alle der code, der wiederholt auf der Liste der Spieler.

Macht es mein code unnötig ausführlich. Ich muss jetzt anrufen my_team.Spieler.Zählen statt nur my_team.Zählen. Zum Glück, mit C# kann ich definieren, Indexer, um die Indizierung transparent, und uns alle die Methoden der internen Liste... Aber das ist eine ganze Menge code! Was bekomme ich für alle, dass die Arbeit?

Kapselung. Ihre Kunden brauchen nicht zu wissen, was geht im inneren von FootballTeam. Für alle Ihre Kunden wissen, es könnte umgesetzt werden, indem der Liste der Spieler, die sich in einer Datenbank. Sie brauchen nicht zu wissen, und dies verbessert Ihre Konstruktion.

Einfach keinen Sinn. Eine Fußball-Mannschaft nicht "haben" eine Liste der Spieler. Es ist die Liste der Spieler. Sagen Sie nicht: "John McFootballer hat sich SomeTeam Spieler". Sie sagen: "John hat sich SomeTeam". Sie don T fügen Sie einen Brief an "einen string s Zeichen", fügen Sie einen Buchstaben in einen string. Sie don ' T fügen Sie ein Buch zu einer Bibliothek, die Bücher, die Sie hinzufügen, ein Buch zu einer Bibliothek.

Genau 🙂 Sie sagen footballTeam.Add(john), nicht footballTeam.Liste.Add(john). Die interne Liste wird nicht sichtbar sein.

InformationsquelleAutor der Antwort xpmatteo

Gibt es viele ausgezeichnete Antworten hier, aber ich möchte kurz auf etwas, das ich nicht sehen erwähnt: Object-oriented design ist über Stärkung Objekte.

Möchten Sie Kapseln alle Ihre Vorschriften, zusätzliche Arbeit und interne details in ein geeignetes Objekt. Auf diese Weise anderen Objekten interagieren mit diesem, nicht haben, um sorgen über alles. In der Tat, Sie wollen einen Schritt weiter gehen und aktiv verhindern anderen Objekten umgehen diese Interna.

Beim vererben von List alle anderen Objekte sehen können, die Sie als eine Liste. Sie haben direkten Zugriff auf die Methoden für das hinzufügen und entfernen von Spielern. Und du wirst verloren haben; zum Beispiel:

Angenommen, Sie wollen sich differenzieren, wenn ein Spieler verlässt, durch wissen, ob Sie im Ruhestand, zurückgetreten oder wurden entlassen. Sie könnte die Umsetzung einer RemovePlayer - Methode, die einen entsprechenden input enum. Jedoch, durch übernahme von List Sie wäre nicht in der Lage zu verhindern, dass den direkten Zugang zu Remove, RemoveAll und sogar Clear. Als ein Ergebnis, Sie haben tatsächlich entmachtet Ihre FootballTeam Klasse.

Zusätzliche Gedanken zur Kapselung... Sie hob die folgenden Anliegen:

Macht es mein code unnötig ausführlich. Ich muss jetzt anrufen my_team.Spieler.Zählen statt nur my_team.Graf.

Du hast Recht, das wäre unnötig verbose für alle clients verwenden die Sie team. Das problem ist jedoch sehr klein im Vergleich zu der Tatsache, dass Sie noch ausgesetzt List Players für alle und jeden, so dass Sie anpassen können mit Ihrem team, ohne Ihre Zustimmung.

Gehen Sie auf zu sagen:

Einfach keinen Sinn. Eine Fußball-Mannschaft nicht "haben" eine Liste der Spieler. Es ist die Liste der Spieler. Sagen Sie nicht: "John McFootballer hat sich SomeTeam Spieler". Sie sagen: "John hat sich SomeTeam".

Du bist falsch über das erste bit: der Tropfen, der das Wort "Liste", und es ist eigentlich offensichtlich, dass ein team funktioniert haben Spieler.

Jedoch, Sie treffen den Nagel auf den Kopf mit der zweiten. Sie nicht möchten, dass clients aufrufen ateam.Players.Add(...). Sie möchten, ruft Sie ateam.AddPlayer(...). Und Ihre Realisierung würde (möglicherweise unter anderem) nennen Players.Add(...) intern.

Hoffentlich können Sie sehen, wie wichtig die Kapselung ist auf das Ziel der Stärkung Ihrer Objekte. Sie möchten, dass jede Klasse seine Arbeit zu tun, ohne Angst vor Störungen durch andere Objekte.

InformationsquelleAutor der Antwort Craig Young

Mein schmutziges Geheimnis: es ist mir egal was die Leute sagen, und ich Tue es. .NET Framework ist verbreitet mit "XxxxCollection" (UIElementCollection für die Spitze von meinem Kopf Beispiel).

Also, was hält mich zu sagen:

team.Players.ByName("Nicolas")

Wenn ich es finde, besser als

team.ByName("Nicolas")

Darüber hinaus, mein PlayerCollection könnte verwendet werden, durch andere Klassen, wie "Club" ohne code-Duplizierung.

club.Players.ByName("Nicolas")

Best practices von gestern, nicht von morgen. Es gibt keinen Grund, hinter den meisten best practices, die meisten sind nur Breite Zustimmung in der Gemeinschaft. Anstatt zu Fragen, die community, wenn er tadelt Sie, wenn Sie das tun, Fragen Sie sich, was ist besser lesbar und wartbar?

team.Players.ByName("Nicolas") 

oder

team.ByName("Nicolas")

Wirklich. Haben Sie irgendwelche Zweifel? Nun, vielleicht Sie brauchen, um zu spielen mit anderen technische Einschränkungen, die verhindern, dass Sie zur Verwendung von List<T> in der realen Anwendungsfall. Aber nicht noch eine Einschränkung, die nicht existieren sollte. Wenn Microsoft nicht dokumentieren, warum, dann ist es sicherlich eine "best practice" aus dem nichts kommen.

InformationsquelleAutor der Antwort Nicolas Dorier

Wenn Sie sagen List<T> ist "optimiert", ich denke, dass Sie möchten, um zu bedeuten, dass es nicht Funktionen wie virtuelle Methoden, die sind etwas teurer. Das problem ist also, dass, wenn Sie setzen List<T> in Ihrem öffentliche API, verlieren Sie die Fähigkeit zum erzwingen von Geschäftsregeln oder anpassen, deren Funktionalität später. Aber, wenn Sie mit dieser geerbten Klasse als intern in Ihrem Projekt (im Gegensatz zum potentiell ausgesetzt ist, zu tausenden von Ihren Kunden/Partnern/anderen teams wie API), dann mag es OK sein, wenn es spart Zeit und es ist die Funktionalität, die Sie duplizieren möchten. Der Vorteil der Erben von List<T> ist, dass Sie beseitigen viele dumme wrapper-code, der ist nur nie was angepasst werden in absehbarer Zukunft. Auch, wenn Sie möchten, dass Ihre Klasse explizit haben genau die gleiche Semantik wie List<T> für das Leben Ihrer APIs dann kann es auch OK sein.

Sehe ich oft viele Leute da sind Tonnen von extra Arbeit, nur weil der FxCop Regel so sagt, oder jemand ' s blog sagt ist es eine "schlechte" Praxis. Viele Male, wendet sich dieser code in design pattern palooza Verrücktheit. Wie viel Leitlinie, behandeln Sie es als Leitfaden, dass kann Ausnahmen.

InformationsquelleAutor der Antwort ShitalShah

Ich wollte nur hinzufügen, dass Bertrand Meyer, der Erfinder von Eiffel und design by contract, hätte Team Erben von List<Player> ohne auch nur mit der Wimper zu zucken.

In seinem Buch Objekt-Orientierte Software Konstruktion, er beschreibt die Implementierung eines GUI-system, wo rechteckige Fenster Kind-Fenster. Er hat einfach Window vererben von beiden Rectangle und Tree<Window> Wiederverwendung der Umsetzung.

Aber C# ist nicht Eiffel. Letzteres unterstützt Mehrfachvererbung und die Umbenennung von Funktionen. In C#, wenn Sie eine Unterklasse, erbt man die Schnittstelle und die Implementierung. Sie können das überschreiben der Umsetzung, aber die Aufrufkonventionen sind direkt kopiert aus der Oberklasse. In Eiffel, jedoch, Sie können ändern Sie die Namen der öffentlichen Methoden, so können Sie Sie umbenennen Add und Remove zu Hire und Fire in Ihrem Team. Wenn eine Instanz von Team ist Verallgemeinerung zurück List<Player> Anrufer verwenden Add und Remove um es zu ändern, aber Ihre virtuelle Methoden Hire und Fire aufgerufen werden.

InformationsquelleAutor der Antwort Alexey

Ich denke, ich bin nicht einverstanden mit Ihrer Verallgemeinerung. Ein team ist nicht nur eine Ansammlung von Spielern. Ein team hat so viel mehr Informationen - name, emblem, collection management/admin-Mitarbeiter, Sammlung von coaching-crew, dann Sammlung von Spielern. So richtig, Ihr FootballTeam Klasse sollte in 3 Sammlungen und nicht aus sich selbst eine Sammlung; wenn es richtig Modell der realen Welt.

Könntest du überlegen, eine PlayerCollection Klasse, die wie die Spezialisierten StringCollection bietet noch einige andere Einrichtungen - wie die Validierung und überprüft werden, bevor Sie Objekte Hinzugefügt oder entfernt werden aus dem internen Speicher.

Vielleicht die Vorstellung von einem PlayerCollection bessere Anzüge Ihre bevorzugte Ansatz?

public class PlayerCollection : Collection<Player> 
{ 
}

Und dann das FootballTeam kann wie folgt Aussehen:

public class FootballTeam 
{ 
    public string Name { get; set; }
    public string Location { get; set; }

    public ManagementCollection Management { get; protected set; } = new ManagementCollection();

    public CoachingCollection CoachingCrew { get; protected set; } = new CoachingCollection();

    public PlayerCollection Players { get; protected set; } = new PlayerCollection();
}

InformationsquelleAutor der Antwort Eniola