Verständnisschwierigkeiten Observer Pattern

[Unregistriert]

Hi!

Ich arbeite gerade das Head First Design Patterns durch und bin beim Observer.

Dort ist ein Beispiel angegeben, wo von einer Wetterstation die Wetterdaten an drei verschiedene Anzeigeobjekte gegeben werden sollen. Das ist mir auch alles recht verständlich. Nur eines erschließt sich mir nicht: Worin liegt der große Vorteil?

Wenn ich das auf das Beispiel beziehe, könnte man doch auch sagen, man will die Wetterdaten einmal pro Sekunde aktualisieren und setzt einen Timer auf.
Die Anzeigeobjekte könnten sich die Wetterdaten (Temperatur, Luftdruck, Luftfeuchtigkeit) als ein Array übergeben lassen und sich mithilfe einer weiteren Methode aktualisieren.

In beiden Fällen müsste man ja die Anzeigeobjekte für den Datenempfang vorhalten.

Bitte um Aufklärung!

 

[Marco13]

Und woher sollten die anderen Klassen wissen, dass sie sich neue Daten abholen können? Ja, dazu müßten sie irgendwie benachrichtigt werden, wenn sich die Daten ändern...
(Ausführlicher?)

 

[Unregistriert]

Angenommen, ich hätte eine Klasse Wetterdaten mit einer Methode:

public String[] getWetterDaten()
{
return WetterDaten[];
}

Dann könnte ich doch eine Methode schreiben:

public void aktualisiereAnzeigen()
{
Anzeige1.update(getWetterDaten());
Anzeige2.update(getWetterDaten());
Anzeige3.update(getWetterDaten());
}

Und immer dann im Timer aufrufen.

Meine Frage ist, warum ist es besser einen Observer zu verwenden?


[/code]

 

[SlaterB]

wo soll diese Methode stehen?
Observer hat den Vorteil der losen Kopplung, die Wetterstation muss nicht die drei Anzeigen kennen, sie muss gar keine kennen, nur das Interface,
jede beliebige auch erst später programmierte Anzeige kann sich dynamisch an und auch abmelden

 

[Unregistriert]

Sie sollte dort stehen, wo die Datenaktualisierung gebraucht wird...

Observer hat den Vorteil der losen Kopplung, die Wetterstation muss nicht die drei Anzeigen kennen, sie muss gar keine kennen, nur das Interface,
jede beliebige auch erst später programmierte Anzeige kann sich dynamisch an und auch abmelden

In meinem Beispiel kennt die Wetterstation die Anzeigeobjekte auch nicht. Sie muss nur ein Datenarray zurückgeben. Was die Objekte daraus machen, ist ihre Sache.
Und man kann auch beliebig viele Anzeigeobjekte in die Liste hinzufügen.

 

[SlaterB]

schon sind wir wieder bei: ausführlicher

was ist
Anzeige1.update(getWetterDaten());
?

was ist da Anzeige1, eine Klasse oder ein Objekt? von welchem Typ? wo steht die Methode,
tausende Fragen

und nochmal ganz genau was dabei der Unterschied zu Observer sein soll, was du vermisst/ als umständlich ansiehst,
schließlich wäre 100% Observer-Pattern schon eine sehr ähnliche Methode in Wetterdaten:

private void aktualisiereAlleObserver() {
for (WetterObserver x : liste) {
x.update(getWetterDaten());
}
}

 

[Unregistriert]

was ist
Anzeige1.update(getWetterDaten());
?

was ist da Anzeige1, eine Klasse oder ein Objekt? von welchem Typ? wo steht die Methode,
tausende Fragen


Das ist ein Objekt der Klasse AnzeigeElement. Die Methode Update übernimmt das Array. Sinnvoll wäre auch eine Methode Show, die z.B. die ArrayDaten als WriteLine auf den Bildschirm bringt.

private void aktualisiereAlleObserver() {
for (WetterObserver x : liste) {
x.update(getWetterDaten());
}
}

Bei der Variante würden ja Anzeige-Elemente automatisch benachrichtigt. Bei meinem Beispiel:
public void aktualisiereAnzeigen()
{
Anzeige1.update(getWetterDaten());
Anzeige2.update(getWetterDaten());
Anzeige3.update(getWetterDaten());
}

Müssten sich die Anzeigeelemente selbst um ihre Benachrichtigung kümmern.

Ich verstehe einfach nicht, warum es die erste Variante besser ist. Sorry, da hakt es bei mir einfach.

 

[SlaterB]

um das Verständnis können wir uns später kümmern, vorerst ist erst festzustellen, worin der Unterschied liegt

mein Code

private void aktualisiereAlleObserver() {
  for (WetterObserver x : liste) {
     x.update(getWetterDaten());
  }
}

ließe sich bei drei Elementen ausschreiben etwa zu

private void aktualisiereAlleObserver() {
  list.get(0).update(getWetterDaten());
  list.get(1).update(getWetterDaten());
  list.get(2).update(getWetterDaten());
}

also quasi

private void aktualisiereAlleObserver() {
  element0.update(getWetterDaten());
  element1.update(getWetterDaten());
  element2.update(getWetterDaten());
}

wie das nun was fundamental anderes als dein Code

public void aktualisiereAnzeigen()
{
  Anzeige1.update(getWetterDaten());
  Anzeige2.update(getWetterDaten());
  Anzeige3.update(getWetterDaten());
}

sein soll, verstehe ich noch nicht, Methodenname, Name der Variablen/ Klassen?

wie kann das eine eine automatische Benachrichtung sein, das andere dagegen etwas, wo man sich selbst kümmern muss,
bei derart ähnlichen Code?

du musst deine Theorien in vielen langen Sätzen beschreiben

 

[Unregistriert]

Das Verständnis allgemein fehlt mir nicht - nur der Aha-Effekt, der mir sagt: "Geil, dieses Pattern haut mich weg!"

Achso, in dem Head First Beispiel ist deine

private void aktualisiereAlleObserver() {
  for (WetterObserver x : liste) {
     x.update(getWetterDaten());
  }
}

in eine Methode der Klasse WetteDaten. Also ungefähr so:

public class WetterDaten
{

//ein paar Datenelemente

// noch ein paar andere Methoden

public String[] getWetterDaten()
{
return WetterDaten[];
}

private void aktualisiereAlleObserver() {
  for (WetterObserver x : liste) {
     x.update(getWetterDaten());
  }
}


}

Bei meiner Version würde ich die aktualisiereAlleObserver-Methode rausnehmen. Beispielsweise hätte man einen Button, der die Aktualisierung der Anzeigen ausführt:

public void aktualisiereAnzeigen()
{
  Anzeige1.update(getWetterDaten());
  Anzeige2.update(getWetterDaten());
  Anzeige3.update(getWetterDaten());
}

private void btnStart_Click(object sender, EventArgs e)
{
aktualisiereAnzeigen();
}

 

[SlaterB]

(ich kann nichts neues beitragen)

 

[Unregistriert]

Ich versteh nicht, warum die eine Variante jetzt das Observer Pattern ist und der Kram, den ich zusammengefrickelt habe, keins ist.

Ich verstehe nicht, warum das eine locker gekoppelt ist und das andere nicht.

Ich verstehe nicht, warum Variante 1 gute OOP ist und das andere nicht.

 

[ARadauer]

"Geil, dieses Pattern haut mich weg!"

Dazu fehlt dir wahrscheinlich eifach noch die Erfahrung. Du bsit einfach noch nicht auf die Probleme gestossen, die dieses Pattern lößt.

 

[ARadauer]

Ich versteh nicht, warum die eine Variante jetzt das Observer Pattern ist und der Kram, den ich zusammengefrickelt habe, keins ist.

Ich verstehe nicht, warum das eine locker gekoppelt ist und das andere nicht.

Ich verstehe nicht, warum Variante 1 gute OOP ist und das andere nicht.

Wenn dein Observerable deinen Observer nicht konkret kennt, sondern nur über das Interface. Kann die Implementierung belieger ausgetauscht werden und ist noch so eng gekoppelt...

 

[Unregistriert]

Könntest du konkrete Beispiele für diese Probleme nennen, die es löst. Das würde mir sicher einen massiven Sprung geben.

 

[ARadauer]

MVC Pattern. Du hast eine oder mehrer Guis, ein Datenmodell und einen Controller die die Anwendungslogik steuert.

Stell dir das Programm Excel vor. Du hast Daten, die werden in Tabellen und diversen Grafiken dargestellt. Jetzt geht der Benutzer her und ändert die Daten.... was nun.. in der Theorie (keine Ahnung wies die Typen wirklich implementiert haben) Wird über eine View (zb das tabellenblatt) eine Methode im Controller angestoßen der die Daten des Model ändert. Nun informiert das Model, alle Views über die Änderung der Daten und diese aktualisieren sich. Das Datenmodell muss nun gar nix über die verschiedenen Views wissen... es können dynamisch weitere Diagramme hinzugefügt werden ohne das irgendwas am Model geändert werden mus...

 

[SlaterB]

Ich versteh nicht, warum die eine Variante jetzt das Observer Pattern ist und der Kram, den ich zusammengefrickelt habe, keins ist.

Ich verstehe nicht, warum das eine locker gekoppelt ist und das andere nicht.

wie ich vorher geschrieben hatte denke ich dass beides das gleiche ist,
dass noch gar kein Unterschied besteht

 

[Unregistriert]

MVC Pattern. Du hast eine oder mehrer Guis, ein Datenmodell und einen Controller die die Anwendungslogik steuert.

Stell dir das Programm Excel vor. Du hast Daten, die werden in Tabellen und diversen Grafiken dargestellt. Jetzt geht der Benutzer her und ändert die Daten.... was nun.. in der Theorie (keine Ahnung wies die Typen wirklich implementiert haben) Wird über eine View (zb das tabellenblatt) eine Methode im Controller angestoßen der die Daten des Model ändert. Nun informiert das Model, alle Views über die Änderung der Daten und diese aktualisieren sich. Das Datenmodell muss nun gar nix über die verschiedenen Views wissen... es können dynamisch weitere Diagramme hinzugefügt werden ohne das irgendwas am Model geändert werden mus...

Achso, dann ist es also wichtig, dass auf die Änderung sofort eine Aktualisierung stattfindet. Würde man es also so machen, wie ich (der Button), hätte man einen Timer, der ununterbrochen die Aktualisierung vornimmt und damit ein Programm wie Excel, massiv ausgelastet würde.
Es geht also um eine Echtzeitänderung.

wie ich vorher geschrieben hatte denke ich dass beides das gleiche ist,
dass noch gar kein Unterschied besteht
[/QOUTE]

Ich dachte, es wäre nur Observer, wenn das Design exakt so nachempfungen wäre.

Hättest du mal ein Beispiel, wann Objekte eng gekoppelt wären?

 

[SlaterB]

wenn die SwingKlasse de.unregistiert.projects.swing.MySwingGUIVersion12Dezember heißt
und in WetterDaten genau diese Klasse auftaucht,

das darf nicht sein, WetterDaten darf sich nur mit allgemeinen WetterObserver-Objekten beschäftigen,
ob nun genau ein oder genau drei Observer oder eine ganze Liste ist dann noch Komfort, man will ja schließlich auch mehrere erlauben

 

[Unregistriert]

Danke!

Ich glaube, ich habe nun kapiert, worum es geht. Dann kann ich ja aufatmen und beruhigt weiterlesen.