Observer Pattern notifyObservers

[knowledge]

Hallo,

bevor ein notifyObservers Aufruf erfolgreich ist, muss ja mittels setChanged das flag auf true gesetzt werden. Im Buch "Designpatterns von Kopf bis Fuß" wurde dies damit erklärt, dass man dadurch eine höhere Flexibilität gewinnt. Am Beispiel einer Wetterstation, welche Observer informiert, wurde erklärt, dass man, wenn sich die Temperatur nur geringfügig ändert so ja permanent die Observer informieren würde. Das Flag gibt jedoch die Möglichkeit, dass informieren etwas feiner zu steuern, z.B. informiere nur, wenn sich ein Temperaturwert um 1 Grad geändert hat. Kennt jemand das Beispiel?

Beim Lesen habe ich mich gefragt, wo da die höhere Flexibilität sein soll. Wenn notifyObservers immer die Observer informieren würde, d.h. kein flag vorher geprüft wird, wäre ich doch trotzdem noch flexibel.

Für das o.g. Szenario würde ich ja folgendes schreiben (Pseudocode):

if(temperatureNew-temperatureOld>= 2)
{
setChanged();
notifyObservers();
}

So müsste ich ja, wenn das Flag nicht da wäre ja nur schreiben:

if(temperatureNew-temperatureOld>= 2)
{
notifyObservers();
}

Wo also bringt mir das setChanged Flag eine höhere Flexibilität? Das habe ich noch nicht ganz verstanden.

Schönes WE

 

[SlaterB]

das ist ein einfacher boolean, ich würde dem nicht zu viel Bedeutung beimessen,

ich könnte mir vorstellen, dass eine Daten-Update-Methode nur
if(temperatureNew-temperatureOld>= 2)
{
setChanged();
}

lautet und ein separat laufender Thread alle 100ms nachschaut, ob hasChanged() true ergibt und dann notifyObservers(); aufruft,
damit das ganze nicht zu oft passiert,
oder es wird generell alle 100ms informiert, ganz egal ob sich was geändert hat oder nicht und hasChanged() gibt dann diese Info,
diese Konstanz widerspricht allerdings ein wenig dem Observer-Prinzip,
andererseits ist das bei 10 Observern vielleicht mit einem Thread leichter zu steuern als wenn jeder einzelne derzeitige Observer kein Observer mehr ist sondern selber ein Thread ist und alle 100ms selber aktiv vorbeischaut


außerdem könnte es mehrere Observer geben, manche interessieren sich für alle Ereignisse,
andere fragen hasChanged() ab und machen evtl. gar nix

so in der Art, nix was man sonst nicht selber programmieren könnte,
allerdings kann ich nicht behaupten, damit alle Gedankengänge aus Pattern-Büchern wiedergegeben zu haben

 

[Marco13]

Hmja, wie auch SlaterB ha(tt/b)e ich Schwierigkeiten, diese "Begründung" mit der "höheren Flexibilität" so nachzuvoellziehen, und alle Beispiele, wo das was bringen würde, würden "gestelzt" wirken.

So einen Thread, der immer läuft und regelmäßig benachrichtigt will man mit diesem Pattern ja gerade vermeiden - deswegen kann das kaum der Grund sein. Ach das
außerdem könnte es mehrere Observer geben, manche interessieren sich für alle Ereignisse,
andere fragen hasChanged() ab und machen evtl. gar nix
kann nicht stimmen: Wenn hasChanged() "false" liefert, werden die Observer garnicht erst benachrichtigt! (Das prüft das Observable schon selbst)

Der einzige Gedanke, der mir käme, wäre, dass man mehrere Änderungen machen will, aber nicht bei JEDER Änderung einzeln die Observer banchrichtigen, sondern erst, wenn alle Änderungen gemacht wurden - etwa sowas wie

void setSomeThings(int a, int b, int c)
{
    setA(a); // Prüften jeweils, ob es eine "echte"
    setB(b); // Änderung war, und setzen ggf. 
    setC(c); // das hasChanged-flag

    // Das benachrichtigt die Observer nur, wenn
    // einer der Aufrufe oben das hasChanged
    // flag wirklich gesetzt hat
    notifyObservers(); 
}

aber das wirkt sehr konstruiert: Eigentlich sollte jede set-Methode selbst notifyObservers aufrufen.

Ein Fall, wo es einen Hauch von Sinn machen würde, wäre, wenn man die Änderungen "Teleskopartig" aufbaut

void setSomeThings(int a, int b)
{
    if (this.a != a)
    {
        this.a = a;
        setChanged();
    }

    // Prüft auf Änderungen, setzt ggf. das changed-flag,
    // und ruft ggf. notifyObservers auf (wordurch das 
    // changed-flag zurückgesetzt wird)
    setB(b);

    // Das benachrichtigt die Observer nur, wenn
    // sie nicht schon von setB aus benachrichtigt
    // wurden...
    notifyObservers(); 
}

Aber ... das wirkt NOCH konstruierter und chaotischer...

 

[knowledge]

verdammt, aber irgend einen sinn muss das doch machen :-( umsonst bräuchte man doch nicht ein booleand und die abfrage in notifyObservers, wenn das nicht sinnvoll wäre

 

[knowledge]

Hmm. Scheinbar hat niemand mehr Lust noch ein bischen zu diskutieren ;-)

 

[Marco13]

Wie SlaterB schon gesagt hat: Es ist nichts, was man nicht selbst durch einen boolean nachbauen könnte - aber zufällig bietet Observable das schon bequem an...

 

[knowledge]

Hallo Marco,

das man das nachbauen kann ist klar Die Frage die sich mir immernoch stellt, wie so ein boolean flag eine Verbesserung bringt gegenüber einem "sofortigen senden". D.h. notifyObservers prüft ja das Flag und informiert erst dann. Eine Prüfung ob informiert werden soll (siehe Temperaturbsp.) ist jedoch auch ohne solch ein Flag möglich.

Also statt:

if(differenz>=2)
{
setChanged();
notifyObserver();
}

nur ein
if(differenz>=2)
{
notifyObserver(); // wenn die Methode immer senden würde
}

D.h. das Flag selber bringt doch keine wirkliche Verbesserung... Das ist mir noch nicht klar, wieso das nicht ohne das Flag gelöst wurde

 

[SlaterB]

notifyObservers() + hasChanged() sind public, können von außen aufgerufen werden,
setChanged() + clearChanged() sind protected, damit ist zumindest eine gewisse Kontrolle Observable selber gegeben bzw. dessen SubKlassen

dies spricht wiederum dafür, dass das ganze dafür ausgelegt, dass jemand anders von außen notifyObservers() aufruft (siehe mein ersten Post),
warum auch immer
vielleicht soll dies ein neuer Thread sein, allein schon weil die update-Methoden aller Oberserver lange brauchen können,
wer nur kurz setTemparature() an einem unscheinbaren Datenobjekt aufruft, rechnet nicht unbedingt damit,
zwei Sekunden warten zu müssen, bis das halbe Programm per Observierung geupdated wurde

wenn man also davon ausgeht, dass in bestimmten Programmen aus irgendeinem Grunde nicht direkt in jeder set-Methode auch das notify() drinsteht,
sondern mehr oder weniger zeitversetzt durcheinander vielleicht durch Einsatz von Threads nofity()-Aufrufe von außen reinkommen,
dann scheint eine solche simple Steuerung zur Vermeidung doppelter notify()-Durchläufe gar nicht so überflüssig,

in einfachen Fällen kann man aber vielleicht drauf verzichten, siehe diese Anleitung, die in zwei von drei Versionen darauf verzichtet
(und es auch nicht näher erklärt)
http://de.wikibooks.org/wiki/Java_Standard:_Muster_Observer

 

[Marco13]

Wie in meinem zweiten Beispiel schon angedeutet: Wenn die Bedingung, unter der die Observer genotified werden sollten, komplexer wird, ist es so vielleicht übersichtlicher. Sowas wie

if (a != newA) { a = newA; setChanged(); }
if (b != newB) { b = newB; setChanged(); }
if (c != newC) { c = newC; setChanged(); }
if (d != newD) { d = newD; setChanged(); }
if (e != newE) { e = newE; setChanged(); }
if (f != newF) { f = newF; setChanged(); }
notifyObservers();

wäre ja effektiv nur durch ein flag vernünftig nachzubauen - wie sollte dieser Codeblock sonst aussehen?

 

[SlaterB]

jeder verfolgt seine eigene Idee nochmal weiter