Listener ohne Objekt

[Garm]

Ahoi.

Ich kriege seit zwei Tagen keine praktikable Lösung für mein Problem, deswegen frage ich jetzt hier

Ich habe mein Prog weitgehend(!) nach dem MVC-Pattern aufgebaut.
Da ich permanent ein Verzeichnis überwachen will, habe ich dem neuen WatchService von Java 7 bedient.
Das klappt gut, nur habe ich (da neuer Thread nötig) den Watcher in eine neue Klasse gepackt, aus der die Logik über das Ereignis informiert wird ( deswegen das (!) ) und das Ereignis verwertet.

Ich möchte nun, dass auch der Controller von dem Watcher informiert wird, dass ein Ereignis ausgelöst wurde.

Ich bin Noob, deswegen verzeigt mir meine Unstrukturiertheit, aber das Programm funktioniert so wie es soll, nur dass eben ein im Controller definiertes Ereignis auf die Watchermeldung folgen soll und der Controller bisher nicht informiert wird.

Meine Idee war logischerweise ein Listener, aber ich habe nix woran ich den binden kann.
Ich kenne mich nicht gut genug aus, so dass mir kein dafür passender Listener einfällt bzw ich "mal schnell" einen zusammen baue, der das tut was ich will.


Ansätze, Vorschläge, Ideen, Lösungen?

cya
Garm

 

[rme]

Hallo,

dein Watcher ist im MVC-Pattern ja ein Model. Du könntest ihn zum Beispiel im Controller beim Starten der Anwendung initialisieren. Eigentlich ist es nicht schlimm, einen eigenen Listener dafür zu basteln: Du erstellst ein Interface mit den Methoden, die der Controller zum Empfang von Ereignissen haben sollte. Der Watcher hat dann eine Menge von Objekten, die dieses Interface implementieren (wobei die Menge hier wohl die Größe 1 hätte, nämlich nur der Controller) und informiert diese in einer Schleife über Ereignisse.

Es gibt allerdings auch eine fertige Möglichkeit: Du könntest deinen Watcher von der Klasse Observable ableiten, da ist alles schon fertig. Der Controller implementiert dann das Observer-Interface.

Übrigens wäre das dann kein MVC, sondern das MVP-Pattern - die Kommunikation zwischen Model und Views geht nämlich eigentlich nicht über den Controller, sondern die Views melden sich als Observer / Listener beim Model an, sodass der Controller nichts von Änderungen im Model erfährt. Bei dir verkommt der Controller dann zu einem Presenter - er steuert beide Richtungen und gibt die Änderungen des Models an die Views weiter.

 

[Garm]

Ahoi.

Hmm Observable....den hatte ich schonmal, aber ich konnte mich da irgendwie zwecks Gedankenverknotung nicht reindenken.
Ich werd mir das jetzt genauer angucken, danke dir

Und danke für die Info, dass meine "fast MVC"-Struktur sogar einen Namen hat *g*

 

[nvidia]

[...]

Übrigens wäre das dann kein MVC, sondern das MVP-Pattern - die Kommunikation zwischen Model und Views geht nämlich eigentlich nicht über den Controller, sondern die Views melden sich als Observer / Listener beim Model an, sodass der Controller nichts von Änderungen im Model erfährt. Bei dir verkommt der Controller dann zu einem Presenter - er steuert beide Richtungen und gibt die Änderungen des Models an die Views weiter.

Natürlich geht die Kommunikation zwischen Model/View über den Controller dafür ist er da, der verarbeitet nämlich den Input der Views und reicht ihn an das Model weiter und die View holt sich die aktualisierten Daten. Und es sind über die Zeit einige Interpretationen des MVC aufgetaucht, unter anderem auch die Kommunkation View <-> Controller <-> Model oder erweitert um ein Application Model etc. Deshalb ist es auch mittlerweile auch mehr eine Familie. Hier finden sich aber reichlich Beiträge zum Thema MVC wenn man die Forensuche betätigt.

Deine Aussage das der Controller zum Presenter verkommt ist falsch. Auch im MVP unterhalten sich das Model und die View direkt. Wie das MVP mal erläutert und definiert wurde ist hier nachzulesen http://www.wildcrest.com/Potel/Portfolio/mvp.pdf. Ist man fertig wird man feststellen das man das so eigentlich noch nie wirklich gesehen hat. Mir sind noch keine Commands/Selections/Interactors oder sogar ein Notification Framework[1] untergekommen. Zumindest nicht abstrahiert und genau das ist es was das MVP ausmacht. Eine noch striktere Trennung und um noch mehr Abstraktion zu schaffen und der Presenter ist dafür da um die oben genannten Dinge zu koordinieren.

[1] Die Java-Listener-Geschichte ist kein Framework. Das was gemeint ist geht schon z.B. Richtung EventBus.

 

[rme]

Dass die Inputs über den Controller gehen, ist mir bewusst - deshalb sprach ich ja von "beide Richtungen" bei ihm, denn im klassischen MVC geht die andere Richtung (Model -> View) nicht über Controller, bei MVP hingegen schon. Allerdings interessiere ich mich nicht sonderlich für sowas, deshalb wirst du wohl Recht haben

 

[nvidia]

][...], denn im klassischen MVC geht die andere Richtung (Model -> View) nicht über Controller, bei MVP hingegen schon. [...]

Beim "klassischen MVP" geht die Kommunikation zwischen Model und View genauso wenig über den Presenter. Die View zieht sich die Daten direkt aus dem Model (bzw. fliegen die Daten über das Notification Framework/Messaging Framework umher). Wüsstest du auch wenn du dich dafür interessieren würdest (siehe verlinktes Pdf).