Schönen guten Tag, meine Damen und Herren. Vorlesungen 9,
die letzte, die ich vor Ihnen zu halten gedenke,
wenn nicht Krankheit oder was anderes bei Axel Schmolitzki oder Heinz Zülikoven dazwischen kommt.
Wir beschäftigen uns heute mit Graphical User Interfaces und dazu
habe ich gestern noch spontan den Ihnen, glaube ich,
auch nicht ganz unbekannten Fred Winkler dazu gebeten.
Der wird so ab circa Viertel vor zwei,
zehn vor zwei wird der sich dann hier vorne hinstellen und
ihnen mit hochgekrempelten Ärmeln den echten Code zeigen.
Ich bin ja noch in so einer Tradition groß geworden.
Der Professor hält die Vorlesung. Der Assi erklärt es den studentischen Hilfs,
erklärt den studentischen Hilfskräften, was der Professor hätte sagen sollen,
beziehungsweise was er sagen wollte, mit dem,
was er gesagt hat.
Und die studentischen Hilfskräfte erklären es dann den Studenten,
was da passieren soll in den Übungen
Also wir werden jetzt dieses stille Postspiel um ein Kettenglied verkürzen,
weil Fred ihnen direkt erzählt, wie das dann,
was ich jetzt hier konzeptionell so ein bisschen vorbereite,
in Java-Code umgesetzt wird.
Worum geht es heute? Ich habe es schon gesagt,
Programmierung von Graphical User Interfaces werden das wie immer am Anfang
so ein kleines bisschen motivieren.
So vieles von dem kommt jetzt hoffentlich ihnen dann auch schon
bekannt vor. Klein bisschen was erzählen über,
was sind diese Gui-Komponenten,
was müssen wir da
alles unterscheiden
Ich denke, sie werden dann auch schon eine Idee davon bekommen,
wenn sie die, na gut,
im Studium haben wir es eben noch nicht nahe gebracht,
aber wenn sie da nicht schon selbst schon ein paar Erfahrungen gesammelt haben.
Also wie kompliziert ist das, etwas zu bauen,
das sich so anfühlt, wie es sich anfühlen soll?
Was kann man da alles falsch machen und was ist es manchmal für ein Wunder,
dass es uns gelingt, Sachen zu bauen,
die sich so bedienen lassen, wie das ein Benutzer,
mit dem man nie darüber gesprochen hat,
aus seiner Kenntnis,
aus der Bedienung von anderen Programmen,
was der erwartet
Fred wird ihnen dann, wie gesagt,
so ein bisschen was über die Java-Realisierung, die von ihnen
auch im Übungsbetrieb erwartet wird, wird der ihnen was erzählen.
Und dann kommen am Ende nochmal ich und wird noch ein bisschen was
ein paar Minuten über das Layout sprechen. Welche unterschiedlichen Möglichkeiten gibt es, Graphical User Interfaces optisch zu gestalten? Welche Möglichkeiten werden ihnen da von den entsprechenden Java-Bibliotheken angeboten? So,
diese Grafik hoffe ich, Haben Sie mittlerweile,
so ist Ihnen schon so vom Angesicht her eingebrannt,
das können Sie schon halbwegs, fast auch schon vollständig auswendig,
wir haben in SE2 so vereinfachte Entwurfsregeln,
die wir so im Laufe des Studiums immer weiter erweitern können,
bis Sie also so diese Art von Modellarchitektur,
den Begriff haben wir so noch nicht eingeführt,
aber auch für größere interaktive Softwaresysteme verwenden können,
woraus besteht die, diese Modellarchitektur, beziehungsweise die,
was sind die Regeln, die diese Modellarchitektur beinhaltet,
Flagzeuge benutzen Services, Services benutzen Materialien und die wiederum bestehen,
nicht im Wesentlichen,
aber unter anderem aus Fachwerden.
Das ist eine direkte Benutzungsabhängigkeit zwischen denjenigen und das, was hier so im Kleingedruckten steht,
ist, dass natürlich auch Fachwerte, Fachwerte beinhalten können.
Das sind dann komplexe Fachwerte, dass Materialien, andere Materialien enthalten können,
also insbesondere können Behälter andere Materialien enthalten können und Services können dann zur Erbringung einer Dienstleistung natürlich auf Atom,
ich weiß nicht, gibt es von Atomar eine Steigerungsform,
also auf fein, sagen wir lieber auf fein granularere Services zugreifen.
Materialien sind, so fangen wir jetzt mal unten an,
Fachwerte sind unveränderlich, wie ich mir habe sagen lasse,
ist die, gerade ist ja rausgekommen, Java 8,
wir werden uns im Laufe der Semesterferien mal angucken,
welche Auswirkungen das haben wird, die Programmiersprachenausbildung,
das betrifft sie dann nicht mehr auf den nächsten Zyklus,
SE1,
2,
was schon angekündigt ist,
dass in Java 9 dann
Value Types enthalten sein werden
Und wenn sie dann mit Java 9 konfrontiert werden,
werden sie sehen, ah, Fachwerte, jetzt ganz einfach,
brauche ich nicht mehr komplizierte Konstruktionen und Verrenkung machen.
Also als wir das gehört haben, das Value-Types in Java,
dann integriert werden als Sprachmittel, dachten wir, Mensch,
da können wir so falsch nicht gelegen haben mit dem,
was wir seit wir, insbesondere Achse, seit Jahr und Tag,
also hier predigen, das so anständige Value-Types,
also die Grundlage für erfolgreiche Systementwicklung sind.
So, Materialien veränderlich, Services,
so wie das hier steht, werden Material übergreifend werden,
fachliche Dienstleistungen angeboten
Heute werden wir uns im Wesentlichen hiermit beschäftigen, mit diesen acht Buchstaben,
also welche Art von Konstruktionshinweisen können wir ihnen geben,
Entwurfsregeln können wir ihnen mit an die Hand geben,
für das Design, für die Implementierung von Softwarewerkzeugen.
Worüber das, da habe ich jetzt, glaube ich,
wenn ich mich richtig erinnere, die letzten zwei Wochen immer schon,
also so mal aus dieser Richtung guckend oder aus jener Richtung guckt und gesprochen.
Das ist also ein ständiges Mantra,
Technologiezyklen und fachliche Zyklen unterscheiden sich voneinander,
wir müssen diese beiden Anliegen voneinander trennen und insbesondere die Interface-Technologien,
die verändern sich ja in einem Maße.
Ach, das verändern sich in hohem Maße. An anderer Stelle,
so in unserem Arbeitsbereich, wir beschäftigen uns da gerade mit Touchtischen.
Ich hatte Ihnen das letzte Woche auch gezeigt.
Da kommen also gefühlt im Drei-Monats-Rhythmus kommt da eine neue Generation
von Geräten raus mit jeweils, also neuer Technologie.
Und mittlerweile haben wir da auch echt Übungen drin,
also unsere Anwendung auf eine neue Generation von Technologie zu portieren.
Aber da kann dieses Gedankengut Kann dort sehr gut angewendet werden.
Für uns im Moment heißt es, Präsentation und Handhabung
wird von der Funktionalität getrennt. Und wir haben uns ja
dann vor allem auch schon mal mit letzter Woche,
wenn man mit dem Entwurfsmuster beobachtet, auseinandergesetzt.
Und dieses Entwurfsmuster ist ja ein Beitrag dazu,
wie kann man die Präsentation von einer Funktionalität derart trennen,
dass keine zyklische Kopplung mehr zwischen denen besteht.
Und heute, das verspreche ich Ihnen,
werden Sie eine Anwendung dieses Entwurfsmusters
Beobachter sehen
Die ihnen helfen wird, im Java-Bereich Werkzeuge konstruieren zu können.
So, jetzt, also mit denen hier den zweiten Spiegelstrich
werden wir heute nicht mehr sprechen. Heute geht es darum,
Werkzeuge zu konstruieren, die für so in den Entwurfsregeln,
soweit wie wir sie jetzt hier ausgebreitet haben,
für die Präsentation und Handhabung zuständig sind.
Damit sie nicht jede Oberfläche Pixel für Pixel gestalten müssen, Gibt es sogenannte Gui-Tool-Kids?
Und diese Gui-Tool-Kids sind Abstraktionen von jeweils zugrunde liegenden Betriebssystem,
Fenstersystem, das ist mit also Geräten dieser Art hier daherkommt.
Diese Gui-Tool-Kids erlauben ihnen grafische Benutzungsoberflächen herzustellen, zu programmieren auf einer Ebene,
sodass sie die Standardelemente für grafische Benutzungsoberflächen darin gleich vorfinden werden.
Das sehen hier so verschiedene Beispiele für für solche Toolkits,
also ob das im Windows-Bereich im Mac-Bereich oder im Unix-Bereich ist, jeder,
so dieser, jeder diese Betriebssystemwelten bringt, ihre eigene,
bringt, ja, bringt, bringt ihre eigenen Toolkits mit,
die jeweils auch mit einem eigenen Look and Feel verbunden sind.
Der Punkt steht hier schon plattformabhängig, sind die,
sind in der Regel, ob es jetzt,
ich weiß gar nicht, ob man sagen kann,
sehr plattformabhängig, also entweder es ist plattformabhängig oder es ist plattformunabhängig,
deswegen könnte man da auch vergessen.
Aber da muss man einfach bedenken, dass Software ist also etwas,
das von Menschen gemacht ist und wenn so die Apple-Leute wollen,
dass sich ihre Oberflächen erkennbar im Verhalten von Windows,
Oberflächen unterscheiden und das umgekehrt auch so ist,
dann sind das eben solche Willensentscheidungen,
die die da treffen und dann kann man take it or leave it,
but don't try to change it.
Es gibt natürlich auch so Bestrebungen und auch Realisierungen von Plattformen unabhängigen Toolkids,
die dann also jeweils eine Teilmenge nur dessen verwenden können,
was also die Plattformen abhängigen Toolkids
an Möglichkeiten mitbringen
Aber so, dass es ein ständiges Ausbalancieren zwischen diesen Ansätzen entscheidend ist,
also auf was man hinaus will,
will ich auf so einem Gerät,
soll es sich genauso anfühlen wie alle anderen Applikationen,
die da drauf laufen oder soll diese Applikationen sich so anfühlen,
wie alle anderen Applikationen, die ich entwickle.
Das ist ja auch eine Entscheidung, die kann ihnen niemand abnehmen. So,
diese Toolkids selber, das sind die, was sind die Ziele,
die mit dem Einsatz solcher Klassenbibliotheken verbunden sind,
so insbesondere sind Die beiden, die wir hier kennenlernen,
der einen Unterschied, werden sie kaum wahrnehmen.
Sie sehen das also in welchem Verhältnis die hier so zueinander stehen.
Das ist so dieses Abstract-Windering-Toolkit, das ist ja das Ursprüngliche.
Java, Guitulkit, darauf aufbauen, ist das Swing-Toolkit,
das wir hier im Wesentlichen verwenden. Das sind objektorientierte,
objektorientierte Bibliotheken, die können sie auch mit der innenbekannten Programmiersprache Java,
Java bedienen. So, jetzt,
sie werden jetzt die erste Swing-Applikation oder nicht ihres Lebens sehen,
sondern ich werde Ihnen jetzt eine Zeiten,
die ich im Schweißen meines Angesichts vor ungefähr anderthalbtausend Jahren programmiert habe.
Das ist ja die Programmierumgebung Ihrer Wahl aus dem ersten Semester.
So, jetzt müssen Sie mal gleich mal nach oben
links gucken. Jetzt ist es schon vorbei,
werden wir hier in der Bundesliga, könnte man sagen,
wir hätten jetzt mal die Slow-Mo sehen, war ja wirklich drin.
So, jetzt, was Sie jetzt sehen werden,
ist, nee, was Sie nicht sehen,
ist,
ich drücke jetzt
den Knopf
Jetzt halte ich den Knopf gedrückt. Ich spüre die Anspannung
. Und jetzt lasse ich den Knopf los.
Früher haben die Leute applaudiert. So, und jetzt zeige
ich Ihnen was anderes, müssen Sie mir glauben.
Ich drücke den Knopf und jetzt ziehe ich mit der Maus
raus und jetzt lasse ich los.
Und es passiert nichts
Dieses Verhalten behalten Sie jetzt bitte mal im Hinterkopf. Ich kenne Leute,
die haben schon eine Nacht lang so an einem Rechner gesessen.
So, mit gedrücktem Finger auf dem Ausknopf. Weil da lief,
als sie den Ausknopf drückten, fiel ihnen ein,
da läuft noch ein Prozess, der nicht unterbrochen werden sollte.
Das hatte der Admin extra gesagt, nicht ausschalten.
Sonst gibt es massiven Ärger, die dahinterstehende Frage,
die wir heute diskutieren, ist, Wann wird ein Ereignis ausgelöst?
Das Button-Pressed-Event wird erst ausgelöst, wenn der Button released worden ist.
Und dann wird es auch nur dann ausgelöst,
wenn der Fokus des Mauszeigers sich immer noch auf dem Knopf befindet.
Also ich kann das jetzt wieder loslassen. Also wir werden uns,
sie werden sich jetzt, wenn sie sich mit grafischer,
mit der Programmierung grafischer Benutzungsoberflächen beschäftigen,
werden sie ja auch jetzt Jetzt spreche ich ja nur von mir.
Ich könnte mir ja so, weil ich so eine rheinische Frohnatur bin,
könnte ich mir ja überlegen,
ich kriege jetzt in der Anwendung ein Button-Presse-Event mit,
wenn ich das will.
So, und jetzt gehen meinetwegen zehn Sekunden ins Land.
Und jetzt könnte ich an anderer Stelle ein Label aufpoppen lassen,
bist du eingefroren auf dem Knopf oder warum lässt du nicht los?
Irgendwas von der Richtung. Weil erst in dem Moment,
wo ich den Knopf loslasse,
sie haben es jetzt gesehen, kommt das Ereignis so,
wie diese Anwendung
programmiert worden ist
An und ich kann also die entsprechende Aktion,
die mit diesem Knopfdruck verbunden ist, auslösen.
Doch mit Feinheiten dieser Art werden sie oder sich
immer so mit Herausforderungen, es sind keine Probleme,
es sind echte Herausforderungen dieser Art werden sie sich beschäftigen müssen.
Jetzt zeige ich Ihnen noch was. Das sind so Sachen,
die sind so selbstverständlich, dass man sich im Alltag eigentlich nicht weiter darum kümmert.
Wenn Sie diese Applikation nehmen und ich verändere jetzt mal die
Größen zwischen diesen beiden Fenstern, dann zeigt diese Anwendung PowerPoint ein,
sagen wir mal, halbwegs nachvollziehbares Verhalten.
Dadurch, dass die Fläche links größer wird,
verkleinert sich rechts der Inhalt, wie heißt denn das,
symmetrisch und links wird halt, werden die Folien größer dargestellt.
Jetzt zeige ich irgendwie mal wieder meine Anwendung,
wenn ich sie denn finde, wo ist sie denn?
Weg. Gott, Panik
Wo ist man? Da ist sie wieder. Jetzt zeige
ich Ihnen mal, wie sich diese Anwendung verhält.
Also meine Anwendung, wenn ich die Größe verändere.
So sieht es aus, wenn man sich keine Mühe gibt beim Design.
Ich meine, es funktioniert noch. Die Behauptung ist,
also ich habe mir extrem viel Mühe gegeben,
bei der Trennung von Generalität und Präsentation,
aber ich habe mir extrem wenig Mühe gegeben mit dem Layout dieser Anwendung.
Und das ist, führt dann dazu, dass ich also auch,
nach dem Motto, sie werden jetzt hier in Informatik,
Wirtschaftsinformatik oder von mir aus auch Softwaresystementwicklung ausgebildet,
aber das, was wir aus Ihnen hier,
das ist jedenfalls nicht der Anspruch dieser Lehrveranstaltung,
wir machen aus Ihnen keine Green Designer.
Sie gehen hier raus mit dem Anspruch Kartoffeldruck, das können wir.
Und dann entweder Sie spezialisieren sich in der Richtung
und lernen das selbst noch,
wie man
grafisch anspruchsvolle Applikationen baut
Oder sie lassen das jemand anders machen, der so Geschmack
hat und technologisches Wissen. Aber das bringen wir ihnen jetzt
hier nicht weiter. So, die Fragen des Tages.
Welche Gui-Komponenten in der Bibliothek Swing stehen uns zur Verfügung?
Wie können wir die mit den fachlichen Klassen verbinden?
Und dann am Schluss zeige ich Ihnen auch noch wenigstens die Möglichkeiten des Layoutings,
also dass das nicht so aussieht oder so ganz kartoffeldruckig aussieht,
wenn man was baut,
die ich hier offensichtlich nicht ausgenutzt habe.
Das hier ist jetzt so eine Auswahl von Komponenten,
die ich bitte sie nicht auswendig zu lernen
Nur, um das mal hier so zwei Auswahlen gibt es,
nur um das mal zu zeigen, also die,
ist dann der nächste Schritt, diese Komponenten werden verwendet,
um eine, können verwendet werden, um eine eigene Oberfläche zu gestalten.
Sie brauchen sich also keine Gedanken darüber machen,
dass wir sie noch sowas wie ein Slider oder ähnliches oder ein Tooltipp,
dass sie sowas implementieren müssen, sondern es gibt eine ganze Reihe von Komponenten,
also die ihnen schon so ein bestimmtes Standardverhalten in einer Applikation nahelegen.
Und es hat halt den entscheidenden Vorteil, ich brauche mich,
um darum nicht mehr zu kümmern, dass wann kriege ich welches Ereignis,
wenn ich einen Knopf verwende und wie kommt es dazu,
dass dieses Ereignis ausgerechnet bei diesem Knopf ankommt?
All das wird von Ihnen ferngehalten. Davon können Sie abstrahieren. Es gibt in jedem dieser Toolkids,
gibt es dann aber auch Stellen, die es Ihnen erlauben,
eigene Komponenten zu integrieren, wenn Sie also das Bedürfnis verspüren,
einen eigenen Treview zu implementieren, das ist manchmal notwendig,
nicht, wenn es komplexe Applikationen sind,
die ein ganz bestimmtes Verhalten an der Oberfläche zeigen sollen,
dann bauen sie sich eben einen MyJ3 oder J. MyTree,
wie auch immer sie den nennen wollen.
Das sind so die Standardkomponenten. Darüber hinaus noch sehen Sie hier
verschiedene Infrastruktur bzw. schon dialogorientierte Komponenten. Sie sind es ja gewohnt,
ohne dass Sie jetzt so die strukturellen Zusammenhänge bereits im Detail kennen,
dass sowas wie ein Dialog oder so eine Standard,
so ein Standardmenü, dass diese, dass die immer gleich aussehen.
Der Hintergrund ist oder der Grund dafür ist,
Das hier in den entsprechenden Goui-Toolkits in den Bibliotheken,
genau solche Komponenten standardisiert, vorgehalten werden.
Sieht dann alles gleich aus,
hat also einen extrem positiven Effekt auf die Eingewöhnung in das Benutzungsverhalten,
wenn sich Dinge gleich verhalten, dann sinkt halt entsprechend die Einarbeitungszeit für das Kennenlernen einer neuen Applikation.
Wir kommen dann ganz am Ende der Vorlesung auch nochmal dazu,
wie wie das dann mit dem Layout zusammengebracht werden kann.
Weil das hier sind jetzt Standardkomponenten,
die zunächst mal ohne jede Kenntnis von einem entsprechenden Umgebenden Container,
das werden wir gleich noch kennenlernen, wie die sich im Layout verhalten.
So, eine Unterscheidung müssen wir machen,
bevor ich ihnen so die strukturellen Zusammenhänge weiter erläutere.
Es gibt für diese Swing-Komponenten gibt es zwei unterschiedliche Arten.
Es gibt sowas wie sogenannte atomare Komponenten, diese atomaren Komponenten,
sind diese Atomtafeln hier nicht mehr sichtbar.
Die werden als kleinste Einheiten betrachtet, da kann nichts weiter drinstecken,
da passiert nachher also die echte, die echte Repräsentation der Oberfläche.
Also sowas wie Knöpfe oder Label, Knöpfe, das,
was man drücken kann, Label, da steht einfach was,
Textfelder, da kann etwas eingegeben werden, das sind atomare Komponenten.
Jetzt kann es mühsam sein, eine Oberfläche ausschließlich aus
atomaren Komponenten zusammenzubauen
Also ich werde jetzt nicht nochmal den Wechsel zu PowerPoint machen.
Und wenn das alles atomare Komponenten sind,
die sich auch noch bei Größenänderungen entsprechend verhalten sollen,
dann haben sie viel zu tun.
Deswegen gibt es die sogenannten Container-Komponenten und die Container-Komponenten des Matrios,
die funktionieren nach diesem Matrioshika-Prinzip in einen Container,
können sie erstens atomare Komponenten hineintun und zweitens wiederum andere Container.
Und dass sie eine Strukturierungsmittel für ihre Oberflächen haben.
Welche Komponenten, also welche Arten von Komponenten können das sein?
Sind das jetzt hier
mal beispielshaft
Wenn sie diese, also wenn sie diese Oberfläche hier jetzt mal nehmen,
dann sehen sie eins, zwei, drei,
vier, fünf, sechs, sieben atomare Komponenten.
Die könnte man jetzt so mit viel Liebe,
könnte man die jetzt Pixel für Pixel,
könnte man die an der Oberfläche, könnte man die an der Oberfläche positionieren,
was sie an der Oberfläche nicht mehr sehen werden,
ist,
dass diese atomaren Komponenten in Containern untergebracht sind.
Und das sind, in unserem Fall sind das jeweils Panels
zu Deutsch Panel
Flächen, könnte man auch sagen. Da sind also die drei Knöpfe,
die liegen in einem eigenen Panel und sie werden das später sehen,
das hat seinen Grund darin,
weil diese drei Knöpfe sollen sich beim Vergrößern verkleinern der Applikation,
das muss man ja immer vorsehen,
man ahnt es ja nicht, ob nicht irgendein Benutzer meint,
er muss sich das mal anders überlegen,
wie groß die Applikation sein soll.
Diese drei Knöpfe sollen sich anders verhalten als das,
was hier in dem Eigentlichen Formular
meinetwegen passiert
Dieses Formular, Sie sehen das hier, das sieht so
gitterartig aus. Und wenn wir später über Layouts sprechen,
dann ist das hier, werden diese, werden diese Elemente,
diese atomaren Elemente, nämlich auch in einem Gitter-Layout verwaltet.
Zunächst mal können Sie hier festhalten,
dass diese vier atomaren Komponenten in einem anderen Container enthalten sind.
Und das ist auch wieder ein Panel. Insgesamt,
und das ist jeweils so das Top-Level-Element,
Klasse, die sich mit der Gestaltung der Oberfläche beschäftigt.
Insgesamt liegt es alles in einem Rahmen, einem Frame,
also Jay, immer für Java.
Und dieses Jay Frame, auf der obersten Ebene,
das beinhaltet eben, wie man das hier auch jetzt,
denke ich, so sehen kann, ein Label.
Das ist dieses Ding hier, ein Panel,
da stecken diese ganzen Labels und Textfelder drin und ein Panel mit den Knöpfen. So,
wenn sie jetzt so auf die Welt in die Welt schauen,
mit diesem Muster oder nach diesem Musterkonstruktionsprinzip, Du hast eine Ebene,
einen Container, einen J-Frame und die Ebene darunter,
in der Regel verschiedene Panels und in diesen Panels dann wahlweise wieder Panels oder dann atomare Komponenten.
Nach diesem Muster werden Applikationen generell aufgebaut. Das ist jetzt hier nochmal,
das ist schwarz auf weiß, dieser Top-Level-Container,
das ist sozusagen der Anfang einer grafischen Benutzungsoberfläche und diese Top-Level-Container in dem Fall,
den ich jetzt gerade beschrieben habe,
ist es ein J-Frame, kann aber auch,
also zum Beispiel sowas ein wie eine Technologie,
die jetzt schon etwas outdated ist,
sowas wie ein Applet sein
So, das dazu. Standteile eines J-Frames sind dann eigentlich immer das,
was man so standardmäßig in einer Applikation haben möchte. Also jede Applikation hat einen Namen,
optional, kann man sowas wie eine Menübar haben,
also da, wo diese Pfeile und Options und so weiter,
help, diese verschiedenen Menüs sind, wer das haben will,
der kann das in so einer Swing-Applikation, deren Top-Level-Container ein J-Frame ist,
auch einblenden und dann gibt es einen Content-Pain, Dieses Content-Pain,
da findet dann die eigentliche Arbeit in der Applikation statt.
So, über diesen Teil wird so dann Fred,
glaube ich, auch noch ein paar Worte verlieren.
Ich möchte Ihnen jetzt nur noch kurz was zu dem Konstruktionsprinzip sagen.
Dass da so eine Art von Oberfläche, die Sie wahrscheinlich,
also mindestens an der Uni, werden Sie die selten sehen.
Wenn Sie dann rübergehen in die Welt außerhalb des Elfenbeinterms,
werden Sie das noch ganz schön viel sehen,
weil so Versicherungsapplikationen, Bankapplikationen, die tendieren dazu,
dass Sie schon mal so 30, 40 Jahre,
50 Jahre alt werden.
Und dass da ist so
ein typisches Mainframe-Hauptmenü
Diese Mainframe-Applikationen, die sind von der Struktur her,
sind die im Großen und Ganzen so gebaut. Solange nicht F13 gedrückt worden ist,
das ist so die Taste mit der, oder drei,
ich weiß es schon gar nicht mehr,
solange diese Taste nicht gedrückt ist, ist das so,
nimm den Input entgegen, prozessiere ihn und dann prozessiere einen gewissen Output.
Was ist das Prozessieren des Outputs, wenn der letzte Input
das gewesen ist, dann mache ich das.
Und ansonsten mache ich irgendwas anderes. Das kann man dann auch noch,
also hierarchisieren, dann heißt die Methode,
nach der das entwickelt worden ist, können Sie damit punkten gegenüber einem Host-Programmierer,
dem Sie sich beim Vorstellungsgespräch outen wollen als Freund,
der Mainframe-Programmierung.
Die Methode heißt Hypo. Hyrakical Input Process Output.
Da kriegen die feuchte Augen, sagen, dass es sowas noch gibt,
junge Menschen, die an der Universität Hypo kennenlernen.
Vielleicht sollten sie es nicht zu weit treiben.
So richtig lernen Sie das ja jetzt hier auch nicht kennen
Die dahinter liegende Idee ist,
dass sie als Anwendungsprogrammierer die vollständige Kontrolle über das Anwendungsprogramm haben.
Dann sagen Sie sich jetzt sehr, was ist denn sonst?
Also wer denn sonst? Also wenn nicht ich,
weil ich bin doch schließlich hier, der Programmierer,
ich implementiere die Hauptschleife und wenn der Benutzer sagt Schluss,
dann ist halt Schluss.
Ansonsten wird irgendwas, wird irgendwas prozessiert. Sie sehen hier
auch, was auch immer der Effizienzbegriff hier ist.
Also das kann man alles machen und so haben ja auch
über zig Jahre die Leute ihre Anwendung programmiert.
Sie sehen die Nachteile,
keine Anleitung
Musik Eins, zwei, drei, wow, das ist,
also, hey, sie sollten Rowdy werden.
Danke vielmals. Ich werde es hier komplett hilflos zusammengebrochen. So,
das fachliche und gruisch-spezifischer Code, das gibt es keine Anleitung,
wie man das voneinander trennt und deswegen,
also kann man Oberfläche und Funktionalität vermutlich auch schwer voneinander trennen und das passiert leider Gottes in diesen Systemen auch nur zu häufig.
Nicht, dass das in den Systemen der Rekonstruktion wir ihnen jetzt beibringen,
nicht auch passieren könnte, aber mindestens haben sie eine gute Chance,
dass diese beiden Anliegen voneinander zu trennen.
Charakteristisch für die Systeme, die wir jetzt bauen,
ist, dass die warten auf sie.
Das tun die anderen zwar eigentlich auch,
aber das ist jetzt so eine spezielle Art des Wartens.
Man nennt es also auch reaktiv
Reaktiv so vom Wort her,
also das ist kein aktives Warten auf, also den nächsten,
auf den nächsten Input, sondern reaktiv in dem Sinne,
dieses Programm, nehmen wir mal hier diese uralte Mac-Oberfläche,
die weiß halt nicht, also was der Benutzer als nächstes tut.
Also das Programm weiß es nicht,
gibt es jetzt hier drauf einen Doppelklick oder gibt es also den Wunsch,
also dieses Ding jetzt zu vergrößern,
wird irgendwas auf dem symbolischen Schreibtisch verschoben,
das wissen wir alles nicht
Und das ist so das Wesensmerkmal der reaktiven Programme. Wir wissen zwar,
dass irgendwann irgendetwas passiert, aber wir wissen nicht genau,
ist es jetzt oder ist es später oder passiert es vielleicht nie.
Wir sind einfach nur vorbereitet darauf, dass mal so eine Aktion ausgelöst wird.
Und das hat jetzt Folgen für das Konstruktionsprinzip.
Dieser reaktiven Software. Sie werden in den Programmen,
die Sie schreiben, werden Sie keine Main-Loop mehr sehen.
Also diese Loop, die da sagt,
why not end the do,
die gibt es nicht
Die gibt es, die gibt es natürlich,
aber nicht in dem von ihnen geschriebenen Code.
Was sie tun, ist, sie betten sich in einen
anderen Code ein, der für sie diese Main-Loop realisiert.
Und sie wissen nur, wenn sie sich da angemeldet haben,
der Tag wird kommen, dass jemand auf den Quid-Button drückt.
Und dann, und ihn auch loslässt. Das kann zwar manchmal dauern,
aber so, wenn er ihn losgelassen hat,
dann erwartet der Benutzer nicht, dass sie fragen wirklich, vielleicht doch.
Also jedenfalls wird, werden sie dann erst reagieren. So,
also der Kontrollfluss liegt außerhalb des von ihnen geschriebenen Quelltextes.
Das ist mit verschiedenen Vorteilen, verbunden,
also sie brauchen sich um die Spezififika der Ereignisverarbeitung nicht zu kümmern,
kann ihnen also völlig gleichgültig sein,
auf welchem Weg die Ereignisse bei ihnen im Programm ankommen.
Hauptsache, sie kommen an und sie brauchen sich dann also
auch nicht, also um diese Feinheiten der Gui,
genau dieser Prozessverarbeitung, der Ereignisverarbeitung kümmern.
Das heißt, es wird ihnen tendenziell nahegelegt,
diese beiden Anliegen auch voneinander zu trennen
Einen Nachteil, also zunächst mal,
es ist ein psychologischer, es ist eine psychologische Herausforderung,
ein Programm zu schreiben, von dem man nicht weiß,
also wann wird eigentlich welcher Teil bedient.
Tja, damit müssen sie alleine fertig werden. Der zweite Nachteil,
das ist der, mit dem wir uns hier beschäftigen,
so zunächst mal braucht es einen gewissen Einarbeitungsaufwand, den diese Gui-Bibliotheken,
weil in die müssen sie sich einbetten und damit sie sich da drin nicht bewegen,
wie ein Elefant im Porzellanladen.
Also sollten sie ein Verständnis davon haben, also wie die
Gui-Bibliotheken grundsätzlich funktionieren. Die grundlegende Idee ist eigentlich hier,
also auch wenn es etwas schwammig ist,
ist hier dargestellt
Da gibt es also den Code, der sich damit beschäftigt,
also so irre Mausbewegungen mitzubekommen und also Ereignisse daraus abzuleiten,
beziehungsweise diese Ereignisse erstmal zu erzeugen.
Und sie sind diejenigen, die dann also mitgeteilt bekommen,
genau dieser Knopf ist gedrückt worden und ich gebe den jetzt an die Stelle,
die, Achtung, Entwurfsmuster beobachte, die sich dafür interessiert,
dass dieser Knopf gedrückt worden ist.
So, und das heißt, was da passiert ist,
es lässt sich so zusammenfassen,
jetzt bitte ich den Popstar-Gaststar Fred
langsam runterzukommen
Das, was da passiert, ist,
dass jede einzelne Aktion wird für jede einzelne Aktion,
wird ein Ereignis erzeugt werden. Ob dieses Ereignis jemals,
also diese Schwelle hier, zu ihrem Code überschreitet,
ist eine Entscheidung, die sie zu treffen haben.
Es gibt nicht nur atomare Ereignisse.
Es gibt auch so zusammengesetzte Ereignisse. Und das Beispiel dafür
habe ich
Ihnen schon gezeigt
Das, was uns eigentlich interessiert, ist,
dass jemand in dem Knopf, den wir implementiert haben,
den Mauszeiger wieder loslässt. Weil sie könnten ganz besonders tückisch,
könnten sie ihre Applikation, um, sagen wir mal,
die Aufmerksamkeit ihrer Benutzer zu steigern,
anders als bei allen anderen Applikationen,
die Aktion schon auslösen in dem Moment, wo der Knopf gedrückt wird.
Das kann lustige Effekte erzielen. Nicht erst mal Loslassen
des Knopfes etwas tun, sondern wenn der gedrückt wird
So, dann sollten Sie vielleicht noch einen Andu-Knopf implementieren,
der seine Funktionalität nur dann zeigt, wenn man den Knopf loslässt.
So, haut so, weiß nicht,
wer von Ihnen guckt, manchmal Monty Python,
sagt es jemandem in Ihrer Generation noch was.
Ja, so, das ist so unter dem Motto,
how to erytate people. Da sind Softwareentwickler gewollt oder ungewollt,
also können da so viele Geschichten, nicht nur erzählen,
Sie können sie auch produzieren.
So, also mit diesen Fragen werden Sie sich auseinanderzusetzen haben
und jetzt kommt Fred und erzählt was ab Folie 23.
Machst du erstmal hier weiter oder nimmst du gleich
deinen eigenen eigenen Laptop