Korrekte OO-Modellierung von Korrespondenzen

Question

Etwas bleibt in meiner Programmierung angezeigt, und es ist, dass zwei Dinge aus einem bestimmten Blickwinkel gleich sind, aber unterschiedlich von anderen. Stellen Sie sich vor, Sie erstellen eine Grafik von Bahnhöfen, die mit Zügen verbunden sind, dann sind die Klassen Vertex und RailStation manchmal gleich, andere nicht.

Also, stellen Sie sich vor, ich habe eine Grafik, die sehr stark Bahnhöfe und Züge darstellt. Dann übergebe ich dieses Diagramm an ein anderes Objekt, das einige Scheitelpunkte löscht, und dann möchte ich, dass die entsprechenden Bahnhöfe weg sind.

Ich möchte nicht Bahnhöfe "Eigenschaften" von Vertices machen, sie sind nicht. Außerdem ist das Problem symmetrisch: Wenn ich eine Bahnstation lösche, möchte ich, dass die entsprechende Ecke weg ist. Was ist die richtige OO-Art zu modellieren oder Korrespondenzen. Ich bin bereit, einige zusätzliche Meilen zu gehen, indem ich einige Support-Methoden oder Klassen schreibe, wenn am Ende die Gesamtnutzung einfach und leicht ist.

Ich verwende derzeit die Smalltalk-Programmiersprache, aber die Frage ist nicht wirklich Smalltalk-spezifisch, denke ich. Ich erwähne es nur, weil Sie in Smalltalk coole Tricks wie das Untersuchen des Call-Stacks durchführen können, was in diesem Zusammenhang hilfreich sein kann.

Aktualisieren: Nun, RailStations sind keine Vertices! Sind sie?

Ok, lassen Sie uns echten Code betrachten, wie in den Antworten gefordert. Lassen Sie mich eine Person mit Kindern modellieren. Das ist die einfachste Sache, oder? Kinder sollten auch ihre Eltern kennen, also haben wir einen doppelt verbundenen Baum. Um das Auflösen von Eltern von Kindern zu erleichtern, modelliere ich die Beziehung zwischen Eltern und Kind als eine Beziehung mit den Eigenschaften Eltern und Kind.

So konnte ich Eltern >> removeChild implementieren: vielleicht wie diese

removeChild: aChild 
    (parent relationshipWith: aChild) disband. 

So ein Elternteil eine Sammlung von Beziehungen hat, nicht von Kindern. Aber jede Beziehung entspricht einem Kind. Jetzt möchte ich solche Dinge tun:

parent children removeAllSuchThat: [:e | e age < 12] 

, die die Beziehung und das Kind entfernen sollte.

Hier entsprechen Beziehungen und Kinder in gewissem Sinne. Also, was mache ich jetzt? Versteh mich nicht falsch, ich bin mir vollkommen bewusst, dass ich das Problem lösen könnte, ohne Beziehungsklassen einzuführen. Aber tatsächlich teilen Eltern und Kinder tatsächlich eine Beziehung, also warum nicht das modellieren und sie benutzen, um zu helfen, doppelte Verbindungen weniger zwingend zu lösen?

Answer 1

In Ihrer Problemdomäne sind Stationen nicht eine Art Vertex? In diesem Fall, warum nicht Station von Vertex ableiten?

Beachten Sie die Verwendung der Phrase "in Ihrer Problemdomäne". Ihr Problem scheint die Verwendung als Bahnhöfe in einer Grafik zu sein. Also ja, in dieser Domäne sind Stationen Eckpunkte. Wenn es eine andere Problemdomäne wäre, sagen wir eine Datenbank über die Bahnhofsarchitektur, könnten sie es nicht sein. Die meisten modernen Sprachen unterstützen eine Idee von Namespaces, damit Sie verschiedene Arten von Entitäten mit denselben Namen in verschiedenen Domänen haben können.

In Bezug auf Ihr Eltern/Kind-Problem sind Sie wieder zu allgemein. Wenn ich mathematische Ausdrücke und Unterausdrücke modelliere, würde ich alle Unterausdrücke löschen und löschen wollen, wenn ich einen Elternteil entferne.OTOH, ff Ich habe rechtliche Verantwortungsbeziehungen in der britischen Bevölkerung modelliert, dann, wenn eine Verantwortung aufgelöst wird (sagen wir wegen einer Scheidung), möchte ich nur die Beziehung entfernen und NICHT das Kind löschen/befreien, das seine eigene unabhängige Existenz hat .

Answer 2

Es scheint, als ob Sie wollen, dass RailStation nur von Vertex erbt (is-a-Beziehung). Siehe smalltalk tutorial bei Vererbung. Wenn Sie also ein Diagramm von RailStations haben, würde ein Objekt, das (generisch) mit Graphen von Vertexes zu tun hat, die Dinge auf natürliche Weise behandeln.

Wenn dieser Ansatz nicht funktioniert, seien Sie spezifischer (vorzugsweise mit echtem Code).

Answer 3

Von Ihrer Beschreibung des Problems haben Sie eine Eins-zu-Eins-Korrespondenz von Stationen zu Vertices und das Löschen einer Station sollte den entsprechenden Vertex automatisch löschen (und umgekehrt). Sie haben auch erwähnt, dass Sie "eine Graphik von Bahnhöfen bauen, die durch Züge verbunden sind", womit Sie offenbar eine Kurve meinen, in der Stationen Knoten und Züge Kanten sind.

Also, in welcher Weise ist eine Station nicht ein Scheitelpunkt? Wenn die Station nur als Knoten existiert und wenn ein Eckpunkt außer als Station nicht existiert, welchen Nutzen sehen Sie dann darin, sie als zwei getrennte, aber verbundene Einheiten zu erhalten?

Wie ich Ihre Situation verstehe, ist Station-isa-Vertex und Vererbung die Art, das zu modellieren.

Answer 4

Ein Beziehungsobjekt ist eine gute Idee.

Ich denke, die geeignete Frage hier ist "welcher Gebrauch sollte davon gemacht werden?".

Wahrscheinlich Eltern und Kind Klassen erweitern die gleiche Person Superklasse, so dass sie einige Attribute gemeinsam haben, Alter zum Beispiel.

In meiner Idee kann ich Folgendes sehen: Eltern und Kind Objekte müssen einander kennen, also müssen beide Klassen eine Verbindung zu der gleichen Beziehung halten. Das Relationship-Objekt behält eine Eins-zu-viele-Beziehung zwischen einem einzelnen übergeordneten Element und einer bestimmten Anzahl von untergeordneten Elementen bei. Es behält einen Verweis auf jedes Person-Objekt.

Auf diese Weise können Sie die gesamte auflösende Logik innerhalb des Relationship-Objekts implementieren, mehr oder weniger anspruchsvoll, wie Sie es wünschen. Sie können das Beziehungsobjekt abfragen, um zu erfahren, welche Mitglieder der Familie Ihren Anforderungen entsprechen, um etwas zu tun. Sie können die Beziehung sicher auflösen (und zerstören), da sie alle Mitglieder kennt und sie bitten würde, die Referenz zu brechen. Dann wäre sie bereit zu zerstören oder bittet ein Mitglied, die Familie zu verlassen und das Beziehungsobjekt beizubehalten am Leben.

Aber das ist nicht alles. Beziehung sollte wirklich eine Oberklasse sein, erweitert um HierarchicalRelationship und PeerRelationship (oder FriendRelationship).

Mit dieser Spezialisierung können Sie Parent (s) und Child (ren) verwenden, um vollständig traversal zwischen anderen Hierarchien zu verknüpfen. Das wahre Konzept dahinter ist, dass Ihre Relationship-Objekte der Schlüssel sind, um die gesamte Gruppe von Person-Objekten (oder Vertex-Objekten) in einer skalierbaren und strukturierten Weise abzufragen und zu organisieren, sodass die gesamte Datendomäne verwendbar ist in jedem Sinne magst du, ob du Gruppen auflösen oder einen bestimmten Weg (oder eine Eisenbahn) zwischen ihnen gehen willst.

Sorry für die große Menge von Metaphoren.

Answer 5

einen Blick auf Ruhm Nehmen http://www.squeaksource.com/Fame.html

Wir verwenden eine spezielle Unterklasse von Collection, die das entgegengesetzte Ende aktualisiert sehen, wenn Sie Elemente hinzufügen oder entfernen. Sie können Ihre Klassen auch mit Pragmas annotieren, um Beziehungen zu kommentieren. Diese Pragmas werden vom Fame-Framework verwendet, um alle möglichen netten Dinge zu erledigen.