Listener erstellen

[usrr]

Hallo,

wie ich gerade so vor mich her programmiere fällt mir auf, dass ich zum wiederholten mal einen Listener implementiere. Eigentlich ist es immer das gleiche: Eine ArrayList, add/remove-Methoden mit Bezug auf ein Bestimmtes Interface.

Ich habe jetzt das Gefühl, dass ich mir unnötige Arbeit mache und, dass es dafür eine schnelle/einfache "Vorrichtung" gibt. Kann mir dazu jemand nähres sagen?

 

[pl4gu33]

ich bin mir gerade nicht sicher, was du wirklich damit meinst
kannst du mal nen bisschen Code posten, dann kann man dir bestimmt besser helfen.... der Begriff "Listener" stört mich hier irgendwie

 

[usrr]

Ich habe eben etwas gegoogled und den Begriff Observer/Observable gefunden. Das müsste das sein was ich braucht. Keine Ahnung woher ich den Begriff Listener habe.

Ich lese mich da gerade ein, es werden sicher noch Fragen auftauchen. Eine habe ich schon. Im Moment wundere ich mich warum "Observer" eine Klasse und kein Interface ist.

 

[eRaaaa]

ich bin mir gerade nicht sicher, was du wirklich damit meinst
kannst du mal nen bisschen Code posten, dann kann man dir bestimmt besser helfen.... der Begriff "Listener" stört mich hier irgendwie

Was stört dich an dem Wort?
-> Galileo Computing :: Java ist auch eine Insel - 10 Architektur, Design und angewandte Objektorientierung

Was ich aber auch nicht verstehe ist, worauf du (usrr) hinaus willst ?! Man kennt deine Listener ja nicht, vlt kann man einen Allgemeinen schreiben den du immer wiederverwenden kannst, vlt aber auch nicht

 

[bygones]

Eine habe ich schon. Im Moment wundere ich mich warum "Observer" eine Klasse und kein Interface ist.

Observer ist ein Interface
Observable ist eine Klasse

 

[usrr]

Galileo Computing :: Java ist auch eine Insel – 7.2 Design-Pattern (Entwurfsmuster)

Und im nächsten Kapitel taucht dann auch der Begriff Listener auf. Daher hatte ich den wohl.

Galileo Computing :: Java ist auch eine Insel – 7.2 Design-Pattern (Entwurfsmuster)

 

[pl4gu33]

Was stört dich an dem Wort?
-> Galileo Computing :: Java ist auch eine Insel - 10 Architektur, Design und angewandte Objektorientierung

ich weiß schon, was nen Listener ist ... ich wollt damit eher darauf hinaus, was er jetzt genau für ein Problem hat bzw. was dieser bezwecken soll

@usrr... Observer ist ein Interface

[EDIT]zu lahm [/EDIT]

 

[usrr]

Das konkrete Proble ist, dass ich einen String brauche, der andere Klassen darüber informiert, dass er geändert wurde. - wahrscheinlich gibts den aber schon vorgefertigt.

 

[bygones]

Das konkrete Proble ist, dass ich einen String brauche, der andere Klassen darüber informiert, dass er geändert wurde. - wahrscheinlich gibts den aber schon vorgefertigt.

der String selbst kann das nicht, aber er sollte ja in irgendeiner Klasse/Struktur stecken.

Andere Klassen melden sich bei dieser Struktur/Klasse als Listener an und die Klasse schickt dann an alle ihre Listener eine Nachricht wenn sich der String geaendert hat.

Kann sein dass dies mit Observable/Observer geht, oder eben du hast deine eigenen Listener.

Listener ist einfach ein Interface - mehr nicht.

 

[usrr]

Genau, dass mache ich ja jetzt schon eine Weile. Aber ich schrieb ja, dass ich vermute, dass man sich an dieser Stelle etwas arbeit sparen kann. Statt immer wieder selbst einen Listener zu implementieren, müsste es doch reichen nur die wesentlichen Dinge zu schreibn.

Gerade die ArrayList und das adden/removen der Listeners, sollte doch immer gleich bleiben.

 

[SlaterB]

dass ein Observer seine Listener in einer Liste organisiern muss usw. ist in der Tat ärgerlicher Standard,
würden alle Klassen von einer ObserverBase-Standardklasse erben, ließe sich das vermeiden,
aber nur für diese 10 Zeilen will man kaum die mächtige Möglichkeit der nur einen Vererbung aufbrauchen

------

ein kleiner Trick kann noch sein, die Listenerarbeit generell in eine eigene, anfangs aus Sparsamkeit statische, Klasse auszulagern,

statt
x.addListener(y);
heißt es dann
Listener.add(x,y);

die Klasse Listener verwaltet allgemein, wer auf wen hört,
die Klasse von x muss sich nur bei der Informierung darum kümmern:

Listener.inform(x, event); 
// gibt das event an alle Listener von x, 
// kann auch gewisse Initialisierungsarbeit übernehmen, etwa x als source im event eintragen

für unterschiedliche Listener sieht es auf diesem Wege allerdings nicht so gut aus

 

[bygones]

Genau, dass mache ich ja jetzt schon eine Weile. Aber ich schrieb ja, dass ich vermute, dass man sich an dieser Stelle etwas arbeit sparen kann. Statt immer wieder selbst einen Listener zu implementieren, müsste es doch reichen nur die wesentlichen Dinge zu schreibn.

wenn die Listener immer gleich sind, dann reicht es ja einmal das Interface und eine Registry zu haben (zb wie Slaters vorschlag).

Aber wie gesagt Listener sind nur Interfaces und die koennen eben immer anders aussehen, andere Methoden, andere Parameter - da gibt es nicht viel zu vereinheitlichen

 

[usrr]

Ich meine gelesen zu haben, dass Sun kritisiert wurde, dass diese Funktionalität nicht in Object implementiert wurde. Ich denke, dass ist was Slater mit "ObserverBase-Standardklasse" meint.

 

[usrr]

Ich habe das Problem als Anlass genommen mir mein eigenes Observer/Observerable-Muster über Generics zusammen zu bauen, da ich mich sowieso seit langem schon damit beschäftigen wollte.

Ich hänge jetzt aber bei der Definition der Observable-Klasse:

class Observable<T>

Wie teile ich Java mit, dass T das Interface Observer implementieren muss?

 

[Flown]

public class A<B extends C>{}

 

[usrr]

Danke. Das hatte ich schon probiert, aber jetzt festgestellt, dass ich noch gar keine Methoden im Interface deklariert hatte.

Edit:

Aber nochmal zurück zu Slaters Kommentar. Wenn man sich nicht um die Möglichkeit der Vererbung bringen möchte, was spricht dagegen, das Observable über ein Feld in die Klasse zu integrieren?

 

[SlaterB]

"Wenn man sich nicht um die Möglichkeit der Vererbung bringen möchte, was spricht dagegen, das Observable über ein Feld in die Klasse zu integrieren? "
also mir ist der Satz zu kompliziert,
wenn du mich irgendwas fragst, dann ausführlicher, mit Beispielcode usw.