"Ist ein" vs "Hat a": welcher ist besser?

Ich stimme mit den anderen Leuten, die sagen, dass HAS-A in diesem Fall besser ist. Sie fragen in einem Kommentar:

  

wenn ich sage, dass ein Portfolio nur ein   Sammlung von Fonds, mit ein paar   eigene Attribute mögen   TotalPortfolio usw. macht das   grundsätzlich nicht zu einem "ist-a"?

Ich glaube nicht. Wenn Sie Portfolio IS-A List<Fund> sagen, was ist dann mit anderen Eigenschaften des Portfolios? Natürlich können Sie dieser Klasse Eigenschaften hinzufügen, aber ist es korrekt, diese Eigenschaften als Eigenschaften der Liste zu modellieren? Denn das ist im Grunde das, was du tust.

Auch wenn ein Portfolio mehr als ein List<Fund> unterstützen muss? Zum Beispiel haben Sie vielleicht eine Liste, die das aktuelle Guthaben der Investitionen anzeigt, aber eine andere Liste, die zeigt, wie neue Beiträge investiert werden. Und was ist, wenn Fonds eingestellt werden und eine neue Reihe von Fonds verwendet wird, um ihnen zu folgen? Historische Informationen sind ebenso nützlich wie die aktuelle Fondszuweisung.

Der Punkt ist, dass all diese Eigenschaften nicht korrekt Eigenschaften einer Liste sind, obwohl sie Eigenschaften des Portfolios sein können.

"nicht immer" die Komposition oder Vererbung oder umgekehrt bevorzugen; sie haben unterschiedliche Semantiken (Bedeutungen); schaue genau auf die Bedeutungen, dann entscheide - es ist egal, ob einer "leichter" ist als der andere, für Langlebigkeit ist es wichtig, dass du die Semantik richtig machst

erinnern: is-a = Typ, hat-a = Eindämmung

In diesem Fall ist ein Portfolio logisch eine Sammlung von Fonds; Ein Portfolio selbst ist kein Typ des Fonds , daher ist die Zusammensetzung die richtige Beziehung

EDIT: Ich habe die Frage ursprünglich falsch gelesen, aber die Antwort ist immer noch dieselbe. Ein Portfolio ist kein Listentyp, sondern eine eigenständige Entität mit eigenen Eigenschaften. Ein Portfolio ist beispielsweise ein Aggregat von Finanzinstrumenten mit anfänglichen Investitionskosten, einem aktuellen Gesamtwert, einer Historie von Werten im Zeitverlauf usw., während eine Liste eine einfache Sammlung von Objekten darstellt. Ein Portfolio ist eine "Art von Liste" nur im abstraktesten Sinne.

EDIT 2: Denken Sie über die Definition von Portfolio nach - es wird ohne Ausnahme als eine Sammlung von Dingen charakterisiert. Das Portfolio eines Künstlers ist eine Sammlung seiner Kunstwerke, das Portfolio eines Webdesigners ist eine Sammlung seiner Websites, das Portfolio eines Investors besteht aus allen Finanzinstrumenten, die ihm gehören, und so weiter. Wir brauchen also ganz klar eine Liste (oder eine Art), um ein Portfolio zu repräsentieren, aber das bedeutet keinesfalls, dass ein Portfolio eine Art Liste ist!

Angenommen, wir entscheiden, Portfolio von List erben zu lassen. Dies funktioniert so lange, bis wir dem Portfolio eine Aktie, eine Anleihe oder ein Edelmetall hinzufügen, und plötzlich funktioniert die falsche Vererbung nicht mehr. Oder angenommen, wir werden gebeten, Bill Gates 'Portfolio zu modellieren und zu finden, dass List keinen Speicher mehr hat ;-) Realistischer werden wir nach zukünftigem Refactoring wahrscheinlich feststellen, dass wir von einer Basisklasse wie Asset übernehmen sollten, aber wenn Wir haben bereits von List geerbt. Das können wir nicht.

Zusammenfassung: Unterscheiden Sie zwischen den Datenstrukturen, die wir wählen, um ein Konzept darzustellen, und der Semantik (Typhierarchie) des Konzepts selbst.

Der erste, weil Sie versuchen sollten, die Komposition gegenüber der Vererbung zu bevorzugen, wenn Sie können.

Es hängt davon ab, ob das Unternehmen ein Portfolio als eine Gruppe (und nur eine Gruppe) von Fonds definiert. Wenn es sogar die entfernte Möglichkeit gibt, dass es andere Objekte enthalten könnte, sagen wir "Eigentum", dann gehe zu Option 1. Gehen Sie zu Option 2, wenn es eine starke Verbindung zwischen einer Gruppe von Fonds und dem Konzept von Portfolio gibt.

Soweit Erweiterbarkeit und Nützlichkeit 1 den leichten Vorteil gegenüber 2 hat. Ich stimme wirklich nicht mit dem Konzept überein, dass Sie immer eines bevorzugen sollten. Es hängt wirklich davon ab, was die wirklichen realen Konzepte sind. Denken Sie daran, Sie können jederzeit umgestalten.

^ Für die meisten Fälle von immer. Wenn es öffentlich ausgestellt wird, dann offensichtlich nicht.

Ich würde mit Option (1) - Zusammensetzung gehen, da Sie möglicherweise eher spezifische Attribute für das Portfolio als die Fonds haben.

Der erste, weil "besteht aus" . = & gt; Komposition

Ich werde mich mit der scheinbar üblichen Meinung unterscheiden. In diesem Fall denke ich, dass ein Portfolio sehr wenig mehr als eine Sammlung von Fonds ist ... Durch die Verwendung der Vererbung erlauben Sie die Verwendung mehrerer Konstruktoren, wie in

und Indexer wie in:

usw. usw.

Wenn Sie Variablen des Typs Portfolio als Sammlung von Fonds mit der zugehörigen Syntax behandeln möchten, ist dies der bessere Ansatz.

oder solche Sachen

IS-A-Relation-Ship repräsentiert Vererbungen und HAS-A-Relation-Ship repräsentiert die Komposition. Für das oben erwähnte Szenario bevorzugen wir die Zusammensetzung, da PortfolioA eine Liste hat und es sich nicht um den List-Typ handelt. Inheritances werden verwendet, wenn Portfolio A ein Listentyp ist, hier jedoch nicht. Daher sollten wir für dieses Szenario Komposition bevorzugen.