# Observer vs Listener



## Tomate_Salat (26. Feb 2010)

Java ist auch ein Insel hat gesagt.:
			
		

> Eine Erweiterung der Möglichkeiten über Observer/Observable sind Listener.


ist mir also schon klar. 

Also ich hab mich in den letzten Tagen verstärkt mit Observern beschäftigt, da ich die schändlicherweise nie eingestzt hatte. Ich meine mal was von ihnen gehört zu haben, aber das ging wohl iwie unter. Als erstes dachte ich : "ach du kacke, wie mvc-freundlich ist jetzt eigentl. dein aktuelles Programm, wenn du nie solche benutzt hast". Dann hab ich mir die FAQ's hier durchgeschaut. Habe eigene simple übungen zu Observern gemacht, dann habe ich das TicTacToe-Beispiel nachgebaut und erkannt: Aha, da sind garkeine "reinen" Observer drinne, sonder nur Listener...Und mit denen Arbeite ich auch! 
Meine Programme haben noch zu viel Abhängigkeiten, was ich mit jedem neuen Projekt auch bemüht bin zu vermeiden. 

Ok, so als ich meine erste Observer-Übung geschrieben hatte, dachte ich mir: hmm, ist aber ganz schön blöd, wenn wirklich JEDER informiert wird. Da muss jeder Observer ja einige Fallunterscheidungen haben, damit er seinen Informationen erkennen kann. 
Das Probelem hat man mit Listenern nicht. Also kam nachdem TicTacToe-Beispiel die Frage: Ist die reine Observerklasse überhaupt noch Zeitgemäß dann, sollte man die so überhaupt noch verwenden? 
klar ist es Praktisch, wenn eine Information raus muss, die ALLE Observer interessiert, aber mir fällt da einfach kein Beispiel ein :bahnhof:

MFG

Tomate_Salat


----------



## SlaterB (26. Feb 2010)

Listener SIND  Observer/Observable, nur eben etwas besser mit spezifischen Events, in denene Infos stecken,
Anmeldung für verschiede Eventklassen (Mouse, Key, Action) usw.

nur weil String eine Klasse ist mit viel mehr Details und Attributen ist, 
kann man doch nicht sagen, dass eine leere Klasse/ ein Interface an sich oder das Typsystem/ Vererbung in Java sinnlos ist


----------



## Tomate_Salat (26. Feb 2010)

SlaterB hat gesagt.:


> Listener SIND  Observer/Observable, nur eben etwas besser mit spezifischen Events, in denene Infos stecken,
> Anmeldung für verschiede Eventklassen (Mouse, Key, Action) usw.



Das ist mir klar ;-)



> nur weil String eine Klasse ist mit viel mehr Details und Attributen ist,
> kann man doch nicht sagen, dass eine leere Klasse/ ein Interface an sich oder das Typsystem/ Vererbung in Java sinnlos ist


Nein, du verstehst mich falsch: nicht zeitgemäß sollte nich heisen: nicht sinnvoll. Mir geht es nur darum, wie man Observer verwenden sollte, also nicht in form von spezifischen Listenern, oder ob Sie nur rein als Basis für Listener dienen sollen.


----------



## maki (26. Feb 2010)

Klar haben Listener Vorteile genenüber reinen Observern, aber wenn man sich zB. das Eclipse DataBinding ansieht, kommt man zum Schluss, dass Listener nicht mehr zeitgemäß sind


----------



## Tomate_Salat (26. Feb 2010)

maki hat gesagt.:


> DataBinding


? :rtfm:


----------



## FArt (26. Feb 2010)

Oft verwendete Nomenklatur:
Observable benachrichtigen die Observer synchron, Listener werden asynchron benachrichtigt.


----------



## SlaterB (26. Feb 2010)

also in Swing werden die Listener aber vom AWT-Thread ausgeführt, oder wie ist asynchron vs synchron zu verstehen?


----------



## FArt (26. Feb 2010)

> also in Swing werden die Listener ... vom AWT-Thread ausgeführt


... was meine Behauptung stützt... 

Synchrone und asynchrone Ausführung ist so gemeint, wie es hier (und überall anders) verwendet wird: java.util.concurrent (Java Platform SE 6)


----------



## ThreadPool (26. Feb 2010)

FArt hat gesagt.:


> ... was meine Behauptung stützt...


Ganz sicher? Ist es nicht vielmehr so das wenn du eine Aktion im Listener startest diese den EDT blockiert? Das ist ziemlich synchron, es sei denn du führst die Aktion in einem eigenen Thread aus.


----------



## SlaterB (26. Feb 2010)

worauf FArt so unverblümt hinwies war nicht, welcher Thread blockierend oder nicht die Listener aufruft,
sondern wann die Events ausgeführt werden,

wenn eine JTable fireTableDataChanged() ausführt, werden nicht direkt die Listener informiert, sondern ein Event erzeugt, 
in eine Bearbeitungs-Warteschlange hinten eingefügt und irgendwann später nach Beeendigung der aktuellen Aufgaben bearbeitet

edit: gar nicht mal wahr, bei AbstractTableModel ist es nicht so, aber bei manchen Events vielleicht wie Mouse/ Key,
oder ich verstehe es immer noch falsch, dann bitte noch korrigieren


----------



## Marco13 (26. Feb 2010)

Meine (perpsönliche) Unterschiedung ist grob: Ein Observer kreigt einen Methodenaufruf, ein Listener einen Methodenaufruf+Event, aber wirklich konsequent (und vor allem: etabliert) ist das natürlich nicht. Eigentlich ist "Observer" nur als ein abstraktes Konzept zu sehen - und dass die Klasse in Java zufällig genau so heißt ist eher "Zufall".....


----------



## FArt (26. Feb 2010)

Die AWT EventQueue ist wieder ein besonderer Fall, weil dort eben nur ein anderer Thread die Bearbeitung (Queue eben) ausführt... aber das Prinzip ist trotzdem das Selbe...


----------



## ThreadPool (26. Feb 2010)

Marco13 hat gesagt.:


> Meine (perpsönliche) Unterschiedung ist grob: Ein Observer kreigt einen Methodenaufruf, ein Listener einen Methodenaufruf+Event, aber wirklich konsequent (und vor allem: etabliert) ist das natürlich nicht. Eigentlich ist "Observer" nur als ein abstraktes Konzept zu sehen - und dass die Klasse in Java zufällig genau so heißt ist eher "Zufall".....



Gut dann gebe ich hier auch mal meine Def. zum Besten wie ich es kennengelernt habe.  Das
Observer-Pattern symbolisiert eine spezielle Ausprägung eines Publish-Subscriber-Mechanismusses.
Die dadurch gekennzeichnet ist, dass das Observable direkt eine Liste von seinen Observern hält und
diese über, wie auch immer geartete Änderungen, benachrichtigt. Asynchronität bekommt man da nur
rein wenn man die Liste durchgeht und für jeden Observer das notify (oder was auch immer) in einem
eigenen Thread ausführt, macht man das nicht ist es synchron.


----------



## Tomate_Salat (26. Feb 2010)

Ich habe immernoch keine Ahnung wie ich Observer einzuordnen habe :-/. Spontan würde ich sagen: als Basis zu den Listenern aber man sollte sie nicht mehr aktiv in seinem Code verwenden. Aber iwie würde ich mir selber da auch widersprechen wollen :-/. 
Im Prinzip gibt es doch keinen Anwendungsfall bei dem man Observer/Observable anstatt Listener nehmen sollte, da man doch im Prinzip alles was man mit Observern auch mit Listernen lösen kann + besser.


----------



## SlaterB (26. Feb 2010)

AbstractList ist wirklich eine dämliche Klasse, es gibt keine Situation in der ich sie nutze, immer nehme ich eine der Subklassen ArrayList oder LinkedList


----------



## Atze (26. Feb 2010)




----------



## Tomate_Salat (26. Feb 2010)

SlaterB hat gesagt.:


> AbstractList ist wirklich eine dämliche Klasse, es gibt keine Situation in der ich sie nutze, immer nehme ich eine der Subklassen ArrayList oder LinkedList



Ein einfaches: Ja hätte mir gereicht ;-)


----------



## André Uhres (26. Feb 2010)

Bei Swing werden die Listener eines Objektes (gewöhnlich eines Models) ausnahmslos in entgegengesetzter Reihenfolge der Hinzufügung benachrichtigt, also nicht asynchron. Es gibt zwar (leider) kein Java Grundsatz, der diese Reihenfolge verlangt, jedoch ist sie sinnvoll, denn nur so kann  Client Code das implementierte Verhalten ändern. Siehe auch EventListenerList (Java 2 Platform SE v1.4.2)
Wenn mit Observable eine Ableitung von der Klasse java.util.Observable gemeint ist, dann hat das einen offensichtlichen Nachteil: wenn die Klasse, die wir von java.util.Observable ableiten wollen, bereits von einer anderen Basisklasse erbt (außer natürlich Object), dann ist diese Option schlicht nicht machbar.


----------



## byte (26. Feb 2010)

Klar, per Komposition:


```
class FooPanel extends JPanel {
  private Observable observable;
  ...
  public void addObserver(Observer observer) {
    observable.addObserver(observer);
  }

  public void foobar() {
    // ...
    observable.hasChanged();
    observable.notifyObservers();
  }
}
```


----------

