Design Patters - Observer

[Volvagia]

Ich hab gerade den FAQ-Beitrag zu den Design Pattern gelesen, und habe mich gefragt, ob folgendes richtig wäre:

Sämtliche Klassen, die Infos von anderen empfangen sollen sich dann über addObservable mit dem Namen aus den Constants registrieren, und andere Klassen über diese die Daten zusenden.

Gibt es bei dem UML etwas zu bemängeln?

 

[Antoras]

Ich würde keine String sonder Integer-Konstanten (Zweierpotenzen) nehmen. Hat den Vorteil, dass eine Klasse bei mehreren Observern registriert werden kann ohne groß Rechenaufwand zu betreiben. Z.B. gibt eine Verknüpfung aus den Konstanten

x = 4 | 16 | 32

immer ein Wert ungleich 0 wenn der Wert wieder mit der Konstante verUNDet wird.

x & 4 = 4; x & 8 = 0; x & 32 = 32

.
Außerdem würde ich die Konstanten nicht in eine extra Klasse auslagern, ich würde sie nicht mal öffentlich zugänglich machen. Du musst sowieso wissen welche Klasse mit welcher kommunizieren muss. Du kannst also verschiedene Registrierungsmethoden schreiben, z.B.

addObserver1(Observer), addObserver2(Observer), addObserverN(Observer)

wobei ObserverX natürlich durch sprechendere Namen zu ersetzten wären.

 

[Volvagia]

Meinst du in etwa so?

Dann hätte ich ja einen erheblichen Mehraufwand.
Obwohl es den Source auf Dauer gesehen übersichtlicher und kürzer machen würde.
Aber aufs Interface könnte ich ja dann gleich verzichten, da ich ja die sich registrierenden Klassen pro Methode/Variable genauer spezifizieren könnte, da sich durch die genau bestimmten Namen Wiederverwendbarkeit ausschließen lässt.

 

[Antoras]

Die Idee mit der Map war soweit schon ok, du kommst nur irgendwann ins Schwitzen wenn du nur eine update(Object)-Methode hast. Das Problem ist ja, dass du wissen musst was mit dem Event, das durch update() verschickt wird, gemacht werden soll. Und woher weist du was das Objekt beinhaltet?

Entweder hast du nur ein Event und verschiedene Implementierungen, die beim Aufkommen eines Events nicht alle benachrichtigt werden sollen (dann ist die Map nützlich) oder du hast verschiedene Events, die alle nur "ihre" Implementierungen benachrichtigen sollen. In letzterem Fall wirst du nicht drumherum kommen, dir jeweils einen spezifischen Observer zu erstellen, andernfalls wirst du zur Laufzeit mit unzähligen Abfragen prüfen müssen welches Event nun von wem bearbeitet werden soll.

 

[Volvagia]

Ach so, ja war gedacht, dass sich alles, was irgendwie etwas empfängt dort einträgt, und alles, was etwas absendet nur an diese Objekte schickt.
Meinst du, ich soll noch einen zusätzlichen String übergeben? So wie z. B. beim ActionEvent?

 

[Antoras]

Ich meine du solltest mal versuchen ein Programm zu schreiben, das sich des Design Patterns bedient. Design Pattern versteht man eigentlich erst wenn man sieht wie sie in einem konkreten Anwendungsfall funktionieren.

Das was du in den UML-Diagrammen bisher dargestellt hast ist viel mehr die Idee hinter dem Pattern und kein Anwendungsfall bei dem diese Idee tatsächlich angewendet wird.

 

[Volvagia]

Ok, danke.
Irgendwie muss man am Ende sowieso sehen, was einem selbst am besten liegt. Der Beste Stil nützt einen nichts, wenn man damit nicht umgehen kann.