Soweit waren wir dabei dazu gekommen, zu sagen,
was Swing leistet, wie man grafische Sachen baut.
Aber eigentlich wollen wir ja grafische Nutzeroberflächen für Softwaresysteme machen.
Und wir hatten ja eingangs besprochen, Werkzeuge sind das,
wo die grafische Benutzeroberfläche ist. Und wir hatten auch schon gesagt,
dass Werkzeuge immer aus die zwei,
aus den zwei Klassen besteht, Werkzeugklasse und UI-Klasse.
Ich war ein bisschen vorhin darüber weggegangen, was die Werkzeugklasse
eigentlich macht. Die Werkzeugklasse hat so eine Mittelrolle,
eine Mittlerwelle zwischen der grafischen Benutzeroberfläche und den fachlichen Klassen,
wozu zum Beispiel der Service gehört und die Materialien.
Ja, die Werkzeugklasse ist dafür zuständig,
diese Übergabe zu machen, die Aufrufe zu machen.
Und die UI-Klasse ist das Eigentliche, was wir sehen.
Diese UI-Klasse wird erzeugt von der Werkzeugklasse, wenn die Werkzeugklasse initialisiert wird,
mit einem Konstruktor wird die im Kontroverty UI-Klasse erzeugt.
Und die UI-Klasse, die wird dazu benutzt,
die baut dann die Komponenten zusammen, zuerst das Große,
dahinter liegende, den Top-Verlevel-Window-Element und dann die nächsten grafischen Elemente,
also die ganzen Container, schiebt die Anordnung,
das ist das,
wenn wir über Low-Any-Out sprechen,
da werden wir
ganz zum Schluss dazukommen und steuert das Ganze
Hier ist es nicht vorgesehen, dass man alle Eigenschaften von
J. Frame oder J. Pennel oder sowas erben muss, nein,
wir sagen da typischerweise einfach nur, das ist ein Frame,
der wird definiert und wir stellen die Werkzeuge zur Verfügung.
Wir sind davon, wir importieren das lediglich,
wir sind da nicht direkt davon abhängig und man macht das,
dass man das teufelig als eine paketinterne Klasse deklariert,
diese User in der Festklasse,
auf die greifen wir von außen nicht zu,
die ist Paket intern,
wir greifen auf das Werkzeug zu
Wir hatten schon gesagt, dass Werkzeuge über Konstruktorparameter übergeben werden,
Services ebenfalls als Konstruktor über Parameter übergeben werden und die Werkzeugklasse.
Den eigenen Konstruktor hat, das war sozusagen die Zusammenfassung,
das haben wir bis jetzt gesagt.
Wenn wir jetzt nochmal zurückgehen zu den interaktiven Systemen, ja,
wir wollen interaktive Systeme bauen und das Kennzeichen durch Systeme,
das war irgendwie ganz am Anfang unserer Veranstaltung in diesem Semester,
war,
dass dieses System im Wesentlichen warten
Sie warten, dass der Mensch etwas tut.
Und dann handeln sie ganz schnell, damit der Mensch nicht
das Gefühl hat, da ist eine große Verzögerung.
Deswegen, sie sind reaktiv. Das hat zur Folge,
dass der Entwickler eigentlich nur weiß, ich bereite alles vor für eine Reaktion.
Ich weiß aber nicht, in welcher Folge Ereignisse dann kommen.
Welches Programm gerade aktiviert wird, was der Benutzer da machen
will, das wissen wir nicht vorher.
Grundsätzlich liegt also die Ablaufsteuerung beim Benutzer und das ist etwas,
was der Entwickler zum Zeitpunkt der Programmierung noch nicht wissen kann.
Also das heißt, der Quelltext kann das nicht enthalten
Mir ist aber gut, die Idee der Events,
der Ereignisse hilft uns dabei, das gut zu steuern,
aber wir müssen nicht ganz genau wissen, wie das passiert.
Wir wissen, wir teilen durch die Trennung, sind wir da ganz gut drauf vorbereitet.
Allerdings müssen wir natürlich die Gui-Bibliotheken kennen, wir wissen, was für Ereignisse die liefern. Zu dieser reaktiven Programmierung ist es so,
dass wir die verschiedenen grafischen Elemente, wir haben das ein bisschen geklappt,
da sieht es ein bisschen pixelig aus, ja,
dass wir diese verschiedenen grafischen Elemente jeweils hinter die verschiedenen Sachen dahinter liegen,
wobei es im Programm, im Betriebssystem,
in der Laufzeitumgebung Software gibt, die die eigentliche Ereignis abfangen,
also wenn sie da einen Mausklick machen,
wenn sie da eine Touch-Büro auf ihren Touchscreen machen.
Diese das Umsetzen in einen Aufruf, das macht das Betriebssystem,
ja, und das Betriebssystem ruft dann unseren Quellcode auf,
der sagt, was macht er, was passiert jetzt hier?
Und das ist das Zusammenspiel der Werkzeug in der UI-Klasse.
Das wäre also die UI-Klasse und die Werkzeugklasse sagt dann,
was passiert da? Lassen wir uns zunächst mit den Events beschäftigen,
wie können solche Events passieren, also diese verschiedenen Mausklicks,
Bildschirmberührungen und so weiter,
werden also vom Systemcode in der grafischen Nutzeroberfläche Registriat vom Betriebssystem bringen,
kommen Sie das übergeben?
Das steht jetzt hier nicht mehr dabei. Es wird ein
Ereignis erzeugt. Dieses Ereignis heißt zum Beispiel Maus over,
wenn die Maus drüber gefahren wird und da kommt dann Prop
dann so ein kleines Fällchen auf oder irgend sowas.
Ja, ein Tech. Manchmal sind das mehrere Events,
die aus einer Bewegung oder aus einer Aktion passieren und
man kann da typischerweise auch größere Ergebnisse daraus zurück zusammengeben und
die werden dann erstmal übergeben an die,
die sich angemeldet haben
Ich hoffe, bei Ihnen klickt es jetzt. Sie haben
das mit diesem anmeldenden Registrieren, haben wir beim Observer-Pattern ja
schon gehabt. Ja, und das ist tatsächlich etwas,
was wir hier auch machen wollen in ganz ähnlicher Weise.
Der Anwender, das sind die Menschen, die davor sitzen,
die machen da irgendwas mit Maus oder Finger oder wie auch immer, lösen Ereignisse aus.
Ja, und die Anwendung soll, dass unsere Software,
das ist unsere Software, soll darauf reagieren.
Ja, und dieses Reagieren passiert durch Lissener, Lissen,
Zuhören, das sind also die, die darauf warten,
dass so ein Ereignis passiert. Und dieses Watten,
die warten auf das Ereignis, weil sie sich,
indem sie sich registriert haben, wie das wieder Beobachtermuster,
in dem sie sich registriert haben, dieses Ereignis aufnehmen,
dieser Benachrichtigungsaktivmechanismus, das ist das, was wir machen,
indem wir keine typische Benutzbeziehung haben.
Sie erinnern sich, wir haben darüber gesprochen, wie kann man solche Zyklen vermeiden.
Und wir müssen nicht, wir können damit auch erreichen,
dass die Abhängigkeit nur in eine Richtung gehen,
nämlich die Komponente muss nicht die Listen da explizit kennen.
Sie meldet sich einfach an für ein Ereignis und die Listener
werden das dann schon verarbeiten.
Das ist das, was wir
dabei erreichen wollen
Das ist das, was ich Ihnen vorstellen möchte,
dieses Konzept, wie Listener aussehen.
Ja, wie muss man vorgehen, um Listener zu schreiben?
Also der Anwendungscode soll aufgerufen werden und das machen wir,
dass wir, indem wir einen Listener Interface benutzen.
Es gibt zum Beispiel in Java die Action Listener,
ja, und die haben dann ein Signal, ein Ereignis,
Action performt oder eine Methode,
die sie aufrufen,
wenn so ein bestimmtes Ereignis eben dieses Action-Ereignis kommt
Der Anwendungscode braucht dann nur die Implementierung zu machen,
was passiert denn als Reaktion auf dieses Ereignis, auf diesen Action-Event.
Und dieses Action-Event wird dann immer, dieser Code wird
dann aufgerufen, weil man hat sich da angemeldet.
Und wenn das Ereignis auftritt, sieht das dazu passt, passiert das.
Ja, also nochmal, wie sieht es aus?
Sie klicken, zum Beispiel, sie klicken, dann erzeugen wir ein Event.
Das Event ist im Objekt lorientiert und es ist ja bei uns alles Objekte.
Sie wissen schon, wir Objekte sind toll.
Also wir machen auch Ereignisse zu Objekten und das übergeben wir
in Lissandon, die sich dafür angemeldet haben.
Das war diese Anmeldung
Und die wiederum bekommen, die aktivieren dann ihre Operation, Action performt.
Und das passiert, das löst dann überhaupt erst eine Handlung aus. Das sieht dann so aus,
wir haben also dieses Interface,
von dem wir gesprochen haben, ja,
das Interface wird dann implementiert von dem Beispiel Listener und die Anwendung selber ruft den Beispiel Liserner auf,
ja, oder Standardin, das ist Teil der Anwendung,
die ist, der ist in den Frame eingebettet,
wohl dann irgendwie ein Button oder irgend sowas ist.
Aber der ist es jedenfalls der,
wenn das Ereignis passiert,
ein Action-Event auslöst
Und das Verhalten ist dann so,
wenn wir das eben bei das Statische,
was gehört zu wem, jetzt das Verhalten,
ich klicke auf den Button, der wird ein Ereignis erzeugt,
dieses eben dieses Objekt und dieses Objekt wird übergeben und die Listener bekommen das und führen ihre Ereignisse aus,
den Code aus, der hinter dem zu den Ereignissen dann gehört.
Wir haben dazu eine Frage, ich glaube, das ist die Frage,
3, nein, den Container Frage 4, ja,
also sie sollen in der Lage sein,
dieses Konzept der Eventverarbeitung zu zu erklären.
Also hier war die Struktur, ja,
der Listener implementiert dieses Interface und gehört zu einem Frame und kennt die Events,
die er einsteuert, aber die Reihenfolge ist dann so,
das Ereignis wird irgendwie erzeugt,
wird und dieses Ereignis wird an den Disner übergeben und der
hat dieses Action performt