Entwurfsmuster Beobachter

[kossy]

Hallo !

Ich habe mal eine Frage zu dem Pattern "Beobachter". Ich verstehe nicht ganz die Verbindung zwischen der Klasse Observable (also dem Subjekt) und dem Interface Observer (Beobachter). In der Klasse Aktie, welche das Subjekt erweitert, wird die Methode setKurswert() genauer definiert und in dieser Methode wird auch notifyObserver aufgerufen.

Ich verstehe jetzt nicht, was die Verbindung zwischen Observable und dem Interface Oberserver zu suche hat und wo nun notifyObserver aufgerufen wird (in Observable oder in Aktie). Vor allem, was bezweckt notifyOberservable im Quellcode?

Ich beschäftige mich auch zum ersten Mal mit soclhen Entwurfsmustern und überlege mir das Buch "Entwurfsmuster von Kopf bis Fuß" vom O´reilly Verlag zu besorgen.

[kingofbrain]

Servus,

also Dein Observable ruft bei sich selbst die Methode notifyObservers auf und benachrichtigt alle registrierten Observer über die update Methode.

Stell es Dir ohne Programmierung vor: Es gibt eine Gruppe von Leuten, die wollen gerne wissen, wie sich Aktienkurse verändern. Die Aktie selbst weiß, wann sich ihr Kurs verändert. Jeder, der jetzt an der Kursänderung interessiert ist, sagt der Aktie, dass er benachrichtigt werden will, wenn sich der Kurs ändert. Ändert sich der Kurs dann wirklich, gibt die Aktie diese Informationen weiter (Methode update an allen registrierten Observern aufrufen). Die Aktie ist das Observable, die Leute sind Observer.

Peter

[kossy]

Ok danke für Deine Erklärung ! Irgendwie klingt es auch ziemlich plausibel, aber anhand des Javacodes kann ich es nicht wirklich nachvollziehen. Ich muss mich wohl wirklich intensiv in das Thema einlesen, sonst machts keinen Sinn.

[kingofbrain]

Das einzige, was in Quellcode oft nicht so plausibel ist, wie bei einer natürlichsprachlichen Erläuterung, ist die Frage, was "kennen" heißt. In der Objektorientierung kann eine "kennt"-Beziehung dadurch ausgedrückt werden, dass eine Klasse eine andere als Attribut hat. So hat in Deinem Beispiel die Klasse Aktie eine Liste an Observables als Eigenschaften. Nur dann kann sie bei der Änderung des Aktienkurses durch diese Liste durchlaufen und jeden einzelnen Observer benachrichtigen.

Ich habe allerdings mit den meisten Design Pattern am Anfang Probleme gehabt, bis ich sie mir "übersetzt" habe.

Peter

[kossy]

Ich habe allerdings mit den meisten Design Pattern am Anfang Probleme gehabt, bis ich sie mir "übersetzt" habe.

Was genau meinst Du mit übersetzen?

[kingofbrain]

In genau so eine natürlichsprachliche Erklärung wie ich sie oben angeführt habe. Die Beschreibungen in Deinem "Head First" Buch (das ich erst lange nach dem GoF Design Pattern Buch gelesen habe) finde ich allerdings auch recht sprechend und gut verständlich.

Peter

[kossy]

Nochmal kurz zu dem Entwurfsmuster. Was ich auch nicht verstehe ist, warum in der methode update(), welche die Klasse Börisaner aus dem Interface Observer implementiert, explizit nach Aktie casten muss.

Mir ist auch immernoch nciht ganz klar geworden, was der ------> von Observer auf das Interface bedeuten soll

[kingofbrain]

Das liegt an Deiner Definition der update-Methode. Du übergibst in der Methode als Parameter ein Observable und ein Object. Der Börsianer weiß aber, dass ihm hier die Aktie übergeben wird. Also castet er das übergebene Object entsprechend.

Der Pfeil vom Börsianer zum Observer heißt, dass der Börsianer das Interface Observer implementiert. Schau Dir hierzu am besten noch mal ein UML-Buch durch, das sind UML Grundlagen.

Peter

[kossy]

Hallo !

Nochmla kurz ne Frage zu dem Thema. Also ich habe mir nun das Buch "Entwurfsmuster" von Kopf bis Fuß besorgt und auch hier wird das Beobachtwer-Muster durchgesprochen. Aber auch hier wird mir nicht ganz klar, weshlab ausgerechnet der Strich mit der Rolle "Beobachter" von dem Interface "Observable" zu dem Interface "Observer" zeigt?

Kann der nciht auch noch der Klasse, die das Interface Observable implementiert zu der Klasse zeigen, welche das Interface Observer implementiert!?

Oder deutet dieser Pfeil daruaf hin, dass hier auf den Supertypen programmiert werden soll !?

MFG

[kingofbrain]

Du willst ja gerade nicht, dass ein konkreter Observer ein konkretes Observable kennen muss. Diese Verbindung regelst Du in den Interfaces / Superklassen, dann hat jede Kind- oder implementierende Klasse sie automatisch. Und es ist dann egal, ob es ein Observable A oder ein Observable B ist, was in Verbindung zu einem Observer C steht. Design Pattern wollen nicht einen Spezialfall regeln (z.B. Aktienbroker interessiert sich für Aktienkurse), sondern so allgemein sein wie möglich (irgendjemand kann sich als Beobachter für ein beobachtbares Objekt anmelden, ob das jetzt ein Vogel ist, den der Vogelkundler beobachtet, oder ein Aktienkurs durch einen Broker, soll in einem allgemeinen Pattern egal. sein).

Peter

[kossy]

Diese Verbindung regelst Du in den Interfaces / Superklassen, dann hat jede Kind- oder implementierende Klasse sie automatisch. Design Pattern wollen nicht einen Spezialfall regeln

Salve Peter !

Danke für Deinen Post. Wenn diese Entwurfsmuster so allgemein wie möglich definiert werden, dann könnte ich doch auch den unteren Pfeil (also von dem konkreten Beobachter zum konkreten Subjekt) auch oben an die beiden Interfaces setzen oder?

Der untere Pfeil soll also vom rechten Interface auf das linke Interface zeigen. Geht das so?

[kossy]

Hallo !?

[perdian]

Hallo !?

Hallo!

Im ernst: Was soll dieses Threadpushing?

[kossy]

Ich möchte gerne eine Antwort auf meine letzte Frage bekommen...

[kingofbrain]

Auch ein Informatiker mit Forumsaktivitäten braucht mal Urlaub. Vielleicht sollte mal einer für Foren einen Thread-Autoresponder programmieren.

Naja, in Deiner Grafik kennt das Observable seine Observer. Das ist auch gut so, weil nur so können die benachrichtig werden. Die Verbindung zwischen der Aktie und dem Broker geht allerdings umgekehrt, hier weiß ein Broker über seine Aktien Bescheid. Das ist semantisch eine ganz eigene Beziehung. Allerdings wird es in der Regel schon so sein, dass auch ein Observer seine Observables kennt (er muss sich ja schließlich als Listener anmelden, wenn das nicht von dritter Stelle gemacht wird), deshalb könnte man durchaus aus der zwischen Observer und Observable gezogenen unidirektionalen Beziehung eine Bidirektionale machen, damit sich beide gegenseitig kennen. Hier wieder der Tipp. Übersetze diese abstrakten Beziehungen / Relationen in natürlichsprachliche "wer kennt wen und warum" Beziehungen, dann wird das sprechender.

Peter