Projekt objektorientiertes programmieren in Java SS08. Event-Handling. Nils Heinrich

Transkript

1 Projekt objektorientiertes programmieren in Java SS08 Event-Handling Nils Heinrich

2 Event-Handling Delegation Event Model / Delegation Based Event-Handling Ereignistypen Ereignisklassen Event Listener / Ereignisempfänger Event Sources / Ereignisquellen Adapterklassen Entwurfsmuster

3 Delegation Event Model/Delegation Based Event-Handling

4 Delegation Event Model/Delegation Based Event-Handling Dieses Kommunikationsmodell ist seit Version 1.1 in die JDK eingeführt. Vorteile zu Vorgänger Modellen: veringerter Nachrichtenverkehr, dadurch Perfomancesteigerung im Nachrichtentransport im AWT. Es erlaubt eine komplette Trennung von GUI- und Anwedungscode, dadurch kann die Übersichtlichkeit und Modifizierbarkeit umfangreicher Projekte verbessert werden.

5 Ereignistypen Ereignistypen werden durch eine Hierachie von Ereignisklassen repräsentiert, die aus der Klasse java.util.eventobject abgeleitet sind. Die Klasse java.util.eventobject fungiert als allgemeine Basisklasse aller Arten von Ereignissen. Die Einzige nennenswerte Fähigkeit der Basisklasse besteht darin, das Objekt zu speichern, das die Nachricht ausgelöst hat. Public Object getsource( )

6 Hierachie der Ereignisklassen

7 Hierachie der Ereignisklassen Die Dokumentation zum JDK unterteilt diese Klassen in zwei große Hierachien. Unterhalb der Klasse ComponentEvent befinden sich alle Low-Level-Ereignisse. Die übrigen Klassen werden als semantische Ereignisse bezeichnet Low-Level-Ereignisse Semantische Ereignisse Transport von elementaren Nachrichten von Fenstern oder Dialogelementen Nicht an ein GUI-Objekt gebunden übermitteln höherwertiger Ereignisse z.b. Ausführen eines Kommandos oder Änderung eines Zustandes

8 Ereignisklassen Auf Grund der Übersichtlichkeit wurden von den AWT-Designern mehrere unterschiedliche Ereignisse zu einer Ereignisklasse zusammengefasst. So ist beispielsweise die Ereignisklasse MouseEvent sowohl für Mausbewegung als auch für alle Arten von Klick- oder Drag-Ereignissen zuständig. Mithilfe der Methode getid und der in den jeweiligen Eventklassen definierten symbolischen Konstanten kann das Programm herausfinden, um welche Art von Ereignis es sich handelt. Die Eventklassen im JDK enthalten keine frei zugänglichen Felder. Stattdessen sind alle Eigenschaften durch set-/get-methoden gekapselt.

9 Ereignisklassen Beispiele: MouseEvent: getpoint( ) KeyEvent: getkeychar( ) InputEvent: getmodifiers( )

10 Event Listeners / Ereignisempfänger Damit ein Objekt Nachrichten empfangen kann, muss es eine Reihe von Methoden implementieren, die von der Nachrichtenquelle, bei der es sich registriert hat, aufgerufen werden können. Damit die nötigen Methoden vorhanden sind, muss der Ereignisempfänger die passenden Interfaces implementieren. Die Interfaces sind aus der Klasse java.util.eventlistener abgeleitet. Die Eventlistener- Interfaces befinden sich im Paket java.awt.event. Je Ereignisklasse gibt es ein EventListener-Interface. Das EventListener-Interface definiert eine seperate Methode für jede Ereignisart dieser Ereignisklasse.

11 Event Listeners / Ereignisempfänger Hierachie

12 Event Listeners / Ereignisempfänger Beispielsweise enthält das EventListener-Interface MouseListener die Methoden: mouseclicked( ) mouseentered( ) mouseexited( ) mousepressed( ) mousereleased( ) die beim jeweiligen Ereignis / Event aufgerufen werden.

13 Event Sources / Ereignisquellen Ereignisquellen sind z.b. Fenster, Dialogelemente oder höhere Programmobjekte. Eine Ereignisquelle sendet nur dann ein Ereignis an einen Ereignisempfänger, wenn dieser sich vorher bei der Ereignisquelle registriert hat. Das JDK lässt auch Multicasting zu. Das bedeutet es können auch mehrere Ereignisempfänger an eine Ereignisquelle registriert sein. Da aber keine Aussage darüber getroffen werden kann in welcher Reihenfolge die Ereignisempfänger abarbeitet werden wird hiervon abgeraten. Die Registrierung erfolgt mit speziellen Methoden, an die ein Objekt übergeben wird, das das jeweilige EventListener-Interface implementiert.

14 Event Sources / Ereignisquellen Die Klasse Component hat z.b. Eine Methode addmouselistener, mit der Objekte, die das Interface MouseListener implementieren, sich bei der Komponente registrieren lassen können. Nach erfolgreicher Registrierung wird bei jedem Mausereignis die entsprechende Methode der wie z.b. mouseclicked( ) mouseentered( )... usw aufgerufen.

15 Adapterklassen Eine Adapterklasse ist eine Klasse, die ein vorgegebenes Interface mit leeren Methodenrümpfen implementiert. Adapterklassen werden dann verwendet, wenn aus einem Interface nur ein Teil der Methoden gebraucht werden. In diesem Fall leitet man einfach eine neue Klasse aus der Adapterklasse ab, anstatt das zugehörige Interface zu implementieren, und überlädt die benötigten Methoden.

16 Adapterklassen Zu jedem Low-Level-EventListener stellt das Paket java.awt.event eine passende Adapterklasse zur Verfügung: FocusAdapter KeyAdapter MouseAdapter MouseMotionAdapter ComponentAdapter ContainerAdapter WindowAdapter

17 Entwurfsmuster für das Event-Handling Das Delegation Event Model / Delegation Based Event Handling bietet verschiedene Möglichkeiten Event-Handler zu implementieren. Diese sind je nach Anwedung besser oder schlechter geeignet. Die Besonderheiten der verschiedenen Möglichkeiten werden an den vier folgenden Entwurfsmustern demonstriert. Die Fenterklasse implementiert die erforderlichen EventListener-Interfaces direkt und registriert sich selbst bei den Ereignisquellen. In der Fensterklasse werden lokale oder anonyme Klassen definiert, die einen EventListener implementieren oder aus aus einer Adapterklasse ableiten. GUI-Code und Ereignisbehandlung werden vollkommen getrennt. In der Komponentenklasse werden die Methoden überlagert, die für das Empfangen und Verteilen der Ereignisse erforderlich sind.

18 Variante 1: Implementierung für das Event-Handling Vorteile: naheliegendes Entwurfsmuster einfach zu implementieren keine weiteren Klassen erforderlichen Nachteile: keine Trennung zwischen GUI- und Anwendungscode. Größere Programme werden unübersichtlich und schwer wartbar. Für jeden Ereignistyp muss eine passende EventListener-Klasse registriert werden. Der Programmcode füllt sich scnell mit Methodenrümpfen.

19 Variante 1: Implementierung für das Event-Handling Fazit: Diese Technik ist bestenfalls für kleine Programme geeignet. Durch die Vielzahl der leeren Methodenrümpfe werden auch kleine Programme schnell unübersichtlich.

20 Variante 2: Lokale und anonyme Klassen Lokale Klassen: Ansatz: In dem GUI-Objekt wird eine lokale Klasse definiert und aus einer geeigneten Adapterklasse abgeleitet. Vorteile: Es muss nicht mehr das ganze Interface implementiert werden. Die lokale Klasse hat Zugriff auf die Membervariablen der Klasse in der sie definiert wurde Nachteile: Keine Trennung von GUI- und Anwendungscode.

21 Variante 2: Lokale und anonyme Klassen Anonyme Klassen: Vorteile: verminderter Aufwand bei kleinen Programmen da keine seperaten Klassen angelegt werden müssen.

22 Variante 3: Trennung von GUI- und Anwendungscode Ansatz: Jedes Objekt kann Ereignisempfänger sein, vorausgesetzt das benötigte EventListener-Interface wurde implementiert. Vorteile: Übersichtlicher Programmaufbau hohe Modifizierbarkeit Nachteile: aufwendig für kleine Programme oder Programme mit wenig Ereigniscode

23 Variante 4: Überlagerung der Event-Handler in den Komponenten Ansatz: Die Event-Handler sollen direkt in der Ereignisquelle überlagert werden. Das aufbereiten und verteilen der Events wird intern über die Methode processevent gesteuert, welche anhand des Ereignistyp spezielle Methoden aufruft. z.b.: protected void processcomponentevent(componentevent e) protected void processfocusevent(focusevent e)

24 Variante 4: Überlagerung der Event-Handler in den Komponenten Der Ereignisempfänger muss mit der addeventlistener-methode oder explizit durch Aufruf der Methode enableevents registriert werden. Protected final void enableevents(long eventstoenable) AWTEvent.XXX ACTION_EVENT_MASK ADJUSTMENT_EVENT_MASK COMPONENT_EVENT_MASK usw...

25 Variante 4: Überlagerung der Event-Handler in den Komponenten Fazit: Diese Variante umgeht das Prinzip des Delegation Event Model komplett. Es hat somit die selben Nachteile des alten JDK bis Version 1.0. Die Dokumentation der JDK empfiehlt ausdrücklich für normale Anwedungen eins der vorherigen Entwurfsmuster zu benutzen.

26 Entwurfsmuster Überblick Variante 1 und 2 Kleine bis mittelgroße Programmen Variante 3 Vorallem bei größeren Programmen von Vorteil Variante 4 Nicht zu empfehlen, nur für Spezialfälle