Während einfache, interface-gesteuerte Ereignisbenachrichtigungs-Frameworks in Java bereits vor dem Kambrium existieren (z. B. java.beans.PropertyChangeSupport), wird es immer häufiger für Frameworks verwendet, Annotations-basierte Ereignisbenachrichtigungen zu verwenden.
Ein Beispiel finden Sie unter JBossCache 2.2 . Die Listener-Methoden der Listener-Klasse sind mit Anmerkungen versehen, anstatt sie einer starren Schnittstelle anzupassen. Dies ist einfacher zu programmieren und einfacher zu lesen, da Sie keine leeren Implementierungen von Listener-Callbacks schreiben müssen, die Sie nicht interessieren (und ja, ich weiß über Oberklassen des Listener-Adapters Bescheid).
Hier ist ein Beispiel aus der JBossCache-Dokumentation:
%Vor%}
Das Problem dabei ist, dass es viel mehr ein involvierter Prozess ist, der den Rahmen zur Unterstützung dieser Art von Dingen schreibt, aufgrund der Annotation-Reflection-Natur davon.
Also, bevor ich mir den Weg freimache, einen generischen Rahmen zu schreiben, habe ich gehofft, dass jemand es schon getan hat. Ist jemand auf so etwas gestoßen?
Sie können dies bereits heute mit EventBus machen.
Das folgende Beispiel stammt aus dem EventBus-Handbuch Erste Schritte . Statusleiste, die basierend auf veröffentlichten Ereignissen aktualisiert wird und keine Statusleistensteuerung / Widget als Listener von Herausgebern registrieren muss. Ohne EventBus muss die Statusleiste vielen Klassen als Listener hinzugefügt werden. Die Statusleiste kann jederzeit erstellt und gelöscht werden.
%Vor%Ein ähnliches Projekt ist ELF (Event Listener Framework) , scheint aber weniger ausgereift zu sein.
Ich recherchiere gerade über Ereignisbenachrichtigungs-Frameworks auf Publish-Subscribe Ereignisgesteuerte Programmierung | Kevs Spring vs Java EE Dev und die folgenden Artikel.
Verwechseln Sie nicht kompliziert für clever. Es scheint mir, dass dies wäre:
if (event instanceof NodeCreatedEvent) like code. Warum das besser ist als Unterklassen von adapter Ich habe keine Ahnung! Das Hauptproblem, das ich hier sehe, sind die Methodenparameter, die einschränken, welche Methoden tatsächlich für welche Ereignisse verwendet werden können, und es gibt keine Kompilierhilfe dafür.
Dies macht Interfaces für Observer-Pattern-Implementierungen wie das Java-Event-Modell attraktiv. Tools wie Eclipse können Autogen-Methode Stubs, so dass Sie die Signaturen nicht falsch erhalten können. In Ihrem Beispiel ist es sehr einfach, den falschen Parametertyp zu verwenden und ihn nie zu kennen, bis ein Ereignis eintritt (was in einigen Monaten ein Fehlerfall sein könnte).
Eine Sache, die Sie versuchen könnten, sind meine Anmerkungen & amp; Prozessor zur Implementierung von Beobachtern und Nullobjekt-Implementierungen. Angenommen, Sie haben
%Vor%und wollte eine Listener-Instanz erstellen. Du könntest schreiben
%Vor%Um eine Quelle für diese Ereignisse zu erstellen, können Sie
schreiben %Vor%Siehe Ссылка , wenn Sie interessiert sind. Könnte dir auch andere Ideen geben.
Ich habe auch über ein generisches Annotations-getriebenes Event-Framework nachgedacht. Ich mag die Vorteile, die die statische Typisierung bietet, aber das aktuelle schnittstellengesteuerte Ereignismodell ist schmerzhaft zu benutzen (hässlicher Code). Wäre es möglich, einen benutzerdefinierten Annotationsprozessor zu verwenden, um einige Kompilierzeitüberprüfungen durchzuführen? Das könnte helfen, etwas von der fehlenden "Sicherheit" hinzuzufügen, an die wir uns alle gewöhnt haben.
Ein Großteil der Fehlerprüfung kann auch zu dem Zeitpunkt durchgeführt werden, zu dem die Listener bei den Ereignisproduzenten "registriert" sind. Daher würde die Anwendung früh fehlschlagen (wenn die Listener registriert sind), möglicherweise sogar zur Startzeit.
Hier ist ein Beispiel, wie das generische Framework, mit dem ich gespielt habe, aussehen könnte:
%Vor% Der Producer verwendet EventSupport , der Reflektion verwendet, um die Ereignisse aufzurufen. Wie bereits erwähnt, könnte EventSupport bei der Registrierung der Ereignis-Listener einige erste Prüfungen durchführen.
Hier hat EventSupport eine statische Methode, die Reflektion verwendet, um den Listener automatisch beim Ereignisproduzenten zu registrieren. Dadurch müssen Sie sich nicht manuell bei der Ereignisquelle registrieren. Ein benutzerdefinierter Annotationsprozessor könnte verwendet werden, um zu validieren, dass sich die @HandlesEventFor Annotation auf ein tatsächliches Feld von ExampleListener bezieht. Der Annotationsprozessor könnte auch andere Überprüfungen durchführen, zum Beispiel sicherstellen, dass die Signatur der Event-Handler-Methode mit einer der Registrierungsmethoden auf ExampleProducer übereinstimmt (im Grunde die gleiche Überprüfung, die zur Registrierungszeit durchgeführt werden könnte).
Was denkst du? Ist es das wert, etwas Zeit in die Entwicklung zu investieren?
Sie können sich auch MBassager ansehen. Es ist annotationsgetrieben, sehr leicht und verwendet schwache Referenzen (somit einfach in zu integrieren Umgebungen, in denen das Lifecycle Management von Objekten von einem Framework wie Spring oder Guice oder Something durchgeführt wird).
Es bietet einen Objektfiltermechanismus (Sie können also NodeEvent abonnieren und einige Filter anhängen, um die Nachrichtenbehandlung auf bestimmte Typen zu beschränken). Sie können auch eigene Anmerkungen definieren, um eine benutzerdefinierte Deklaration Ihrer Handler zu erhalten.
Und es ist sehr schnell und ressourceneffizient. Sehen Sie sich diesen Benchmark an, der ein Leistungsdiagramm für verschiedene Szenarien mit Guava oder mbassador zeigt.
Tags und Links java events annotations notifications