Objektorientierte Paradigma Frage

Meine Antwort ist eine Kombination mehrerer vorhandener Antworten.

Das wesentliche Problem ist hier, dass es hier ein verstecktes Konzept gibt. Die Methode redet nicht wirklich über das Laborobjekt oder das Objekt, sondern über die Beziehung zwischen ihnen. (Wie von @dacris und @vs vorgeschlagen.)

Eine Möglichkeit, mit solchen Situationen umzugehen, ist die Verwendung einer Sprache mit doppeltem Versand (Danke, @Ken.)

Eine andere Möglichkeit ist, automatisch generierten Code zu haben (Danke @vs.). In diesem Fall gäbe es Methoden in beide Richtungen.

Aber oft sind diese Lösungen nicht praktikabel - das Ändern ganzer Sprachen scheint übertrieben.

Die automatisch generierte Lösung gibt uns jedoch einen Einblick. Beide Techniken sollten legal sein. Sie können also beide Techniken manuell implementieren.

Wenn Sie sich jedoch nicht wiederholen wollen, macht dieser Ansatz deutlich, dass ENTWEDER-Richtung legal ist. Also schwitze es nicht zu sehr.

Wenn Sie ein System codieren, in dem das Objekt Person außer explodierenden Dingen noch andere Verwendungen hat, wäre es besser, wenn die Kopplung von Lab zu Person geht (dh die Methoden auf das Lab-Objekt anwenden), so dass das Person-Objekt sein kann an anderer Stelle verwendet werden, ohne sich mit Änderungen am Lab-Objekt oder den Explosionsmethoden zu befassen.

... und umgekehrt. Wenn alles, was eine Person macht, Dinge explodiert, dann sollte die Logik da sein, um das Labor sauber und makellos zu halten (was für Labors wichtig ist!).

Vielleicht möchten Sie etwas über die Muster Observer und Publish / Subscribe lesen. Was Sie beschreiben, ist so ziemlich die klassische Anwendung für das Observer-Muster. Das Pub / Sub-Muster ist im Grunde die gleiche Idee, die etwas abstrahiert wurde, um die Skalierung zu unterstützen.

In jedem Fall, wenn man bedenkt, wie bekannt dieses Muster bereits ist, können Sie seine Konvention auch befolgen, es sei denn, Sie treffen eine Situation, in der Sie wirklich davon überzeugt sind, etwas anderes zu tun.

Denken Sie, als würden Sie Englisch sprechen. Die allgemeine Regel ist, dass Verben (und Methoden) so viel wie möglich "aktive Stimme" haben sollten - das heißt, ein Objekt sollte etwas tun, anstatt etwas damit zu tun zu haben.

Wenn es ein Ereignis ist, macht passive Stimme ein wenig mehr Sinn - das Labor sollte wissen, was Personen darin sind, aber eine zufällige Person (sogar eine, die im selben Labor arbeitet) sollte wahrscheinlich nicht, also eine Benachrichtigung, dass die Das Labor explodierte am besten vom Labor selbst. Aber in diesem Fall geht es um die persönliche (oder Team-) Präferenz.

Sie haben Recht. Ich denke, das ist eines der Hauptprobleme der meisten heutigen objektorientierten Systeme: Oft scheinen Methoden einem Objekt "zuzuordnen", oft aber nicht.

Systeme mit Mehrfachversand vermeiden dieses Problem sauber. Zum Beispiel könnten Sie in Dylan etwas sagen:

(Ich bin mit der Seite c2.com MultiMethods verlinkt, weil ich denke, dass es die schlechteste Aufgabe hat, dies zu beschreiben. Wikipedia hat eine Seite für Multiple_Dispatch, aber sein Beispiel ist ziemlich schrecklich.)

Ich bin mir nicht ganz sicher, was Ihr Beispiel bedeutet, aber ein

Ein exzellentes Buch, das genau das hat, was Sie wollen, ist Anwenden von UML und Mustern von Craig Larman.

Das Buch spricht ausführlich über die Zuweisung von Verantwortlichkeiten. Sie können beispielsweise das Information-Expert-Muster verwenden. In diesem Fall ist das Objekt, das die meisten beteiligten Variablen kennt, derjenige, dem die Methode zugewiesen wurde.

Ich denke, dass es eher mit der realen Welt und Ihrer Programmierkonvention als mit allgemeinen guten Praktiken zu tun hat. Für Ihr Englisch bevorzuge ich immer noch Call-Leute.notify (lab). Wenn Sie jedoch möchten, dass Ihr Labor Daten darüber hat, wer es anruft, welche Person, können Sie lab.isNotifiedBy (people) ausführen.

Die gute Übung hier ist, dass es für Sie und Ihren Kollegen Sinn macht, wenn sie sich den Code ansehen, sie verstehen, was sie tut, wenn sie eine Methode finden wollen, wissen sie, wo sie anfangen sollen, anstatt nur weiter zu suchen oder zu fragen du

Ich mag es, solche Dinge zu entwerfen:

In diesem Fall möchte ich ein neues Objekt vorstellen - LabExplosion

Bewahre dann ein Repository von LabExplosions auf und mache etwas wie:

  

Was ist die beste Vorgehensweise hier?

Es hängt von Ihrem Anwendungsfall ab, wie wird der Benutzer das System verwenden? Würde es ein Labor sein, das von einem Person "geblasen" wird? oder der Anwendungsfall des Systems ist es, einige Person explodieren Labs ?

  

oder vielleicht ist es nicht einmal wichtig: S

Am Ende ist das Ergebnis dasselbe, aber wichtig ist hier die Semantik des Codes. Wenn es albern klingt, dass Labs von Leuten geblasen werden, dann tu es nicht.

Also ist die goldene Regel, wie BobTurbo erwähnt, der "Informationsexperte" (siehe: ) GRASP ) im System und geben dem Objekt die Kontrolle.

Normalerweise definieren Sie eine Benutzerhistorie oder einen Bericht darüber, wie das System verwendet werden soll, wenn zum Beispiel die Erzählung lautet:

  

Wenn eine Person etwas tut, muss jeder im Labor benachrichtigt werden.

Dann bedeutet für mich, dass ein Person in einem Lab funktioniert, wenn er erstellt wird, kann diese Person das Labor erhalten, an dem er arbeitet, und sich registrieren, um benachrichtigt zu werden, was in diesem Labor passiert.

Da das Labor die Liste der zu benachrichtigenden Personen hat, ist es sinnvoll, das Labor zu sein, das die Benachrichtigung durchführt (die Person gibt Lab in diesem Fall die Kontrolle)

Dann könnte wahrscheinlich Person wie folgt definiert werden:

Also macht die Person etwas im Labor, in diesem Fall die öffentliche Methode blowUpLab , die gerade das Labor der Person sprengt, indem sie die Methode boom! des Labs aufruft.

Der Lab wiederum führt die Methodenaktionen aus und benachrichtigt alle Abonnenten am Ende:

Dies ist das Beobachtermuster.

Schließlich erstellt Ihre Haupt-App Personen und Labs und führt den Anwendungsfall aus:

Diese Hauptanwendung erstellt drei Personen, mit einigen Labs, nur zwei von ihnen sind verwandt (Scott und Gordon)

Zufällig erhält einer von ihnen die Nachricht blowUpLab und führt die Methode aus. Das Labor wird wiederum alle Abonnenten dieses Labors benachrichtigen.

Wenn also James Hetfield sein Labor bläst, wird niemand benachrichtigt :)

Der Punkt ist Beschreiben Sie Ihren Anwendungsfall und identifizieren Sie den Informationsexperten dort. Geben Sie dem Objekt das Steuerelement, und lassen Sie dieses Objekt das Steuerelement auf ein anderes Objekt anwenden, aber nur gemäß Ihrem Anwendungsfall

Ich hoffe, es macht Sinn.