So, in diesem Teil der Vorlesung beschäftigen wir uns jetzt
mit dem Beobachtermuster, dass wir gut einsetzen können,
um den Werkzeugmaterialeinsatz, insbesondere Werkzeuge zu implementieren.
Dazu haben wir hier ein paar neue Fragen.
Sie sehen schon elf und zehn und elf,
haben wir sich hier ein bisschen rein verirrt.
Die behandeln wir in der nächsten Veranstaltung, wenn wir Entwurfsmuster insgesamt vorstellen.
Zunächst dazu, warum wollen wir Zyklen vermeiden,
Informatiker wissen schon, Zyklen sind irgendwie böse.
Und das ist hier bei der Benutzbeziehung nicht anders.
Und dann gehen wir über das Beobachter Er muss da weiter.
Unser Problem ist es, dass wir sehr viele Dinge haben,
sehr viele Teile in einen Entwurf, die miteinander zu tun haben.
Das, was wir vorhin dargestellt haben mit Werkzeugen,
Materialien und Fachwerten und Services, sieht ja sehr einfach aus.
Die Problematik besteht darin, dass wir sehr viele Elemente haben.
Und dieses Jahr vielen Elemente, wenn die alle voneinander abhängen,
wird es schwierig, zu überschauen, schwierige Änderungen zu machen,
schwierige Updates zu machen, schwierig zu testen.
Alles wird schwierig. Und das ist es,
was wir vermeiden wollen,
enge Kopplung
Sie wissen das schon von Modularität. Enge Kopplung ist irgendwie schwierig
. Und wir wollen mal die Kupplung im Dynamischen betrachten.
Also Ereignisse, Aufrufe, Signale. Ein Aufruf,
da ist es so, dass ein Klient,
ein Dienstleister aufruft und erwartet eine bestimmte Dienstleistung.
Mein Ereignis ist es so, ein Erzeuger.
Irgendwo passiert etwas und das leider mir weiter.
Und wir kümmern uns nicht darum, ob tatsächlich etwas passiert.
Und ein Signal ist noch wieder ein bisschen eine andere Form
von Interaktion
Es ist etwas passiert, wir senden es an alle und
eigentlich ist uns egal, ob jemand zuhört oder nicht.
Also so ein bisschen wie Rundfunk. Beim ersten ist es so,
wie ein tatsächliches Kommunikation zwischen zwei Partnern. Das zweite ist,
dass man einen Dienst, dass es einen Dienst gibt,
der hoffentlich reagiert, aber man weiß es nicht ganz genau.
Und das dritte ist, dass man einfach nur sendet und etwas tut.
Diese haben unterschiedliche Sachen, haben unterschiedliche Kopplungen,
weil hier zum Beispiel ist direkt eine synchrone Beziehung.
Wir wollen etwas zurückhaben, wir warten darauf, geben,
wenn Tier viel weniger ist.
Das verdienen schon bei den Leuten klar.
Und in Java haben wir unterschiedliche Unterstützung für diese Verfahren.
Das ist das Erste, würde in Java funktionieren über eine Assoziation.
Das heißt, man hat eine Referenz eines anderen Exemplars
und man kann die Nachricht zurückbekommen.
Das Zweite gibt es in Java direkt nicht.
Es gibt nicht wirklich so einen Verteiler, aber man kann es nachbilden.
Man kann eine Registry bauen und das Dritte,
das gibt es in Java auch nicht.
Das könnte man auch bauen, indem man das
als über ein Innenverteidigungssystem realisiert
Interessant ist es ja, und deswegen das Bild,
was wir vorher hatten, mit den vielen Abhängigkeiten,
was passiert in großen Systemen bezüglich Änderungsaufwand.
Das ist häufig der Knackpunkt, wenn es darum geht,
ein System über längere Zeit weiterzuentwickeln. Der Änderungsaufwand, was passiert,
was muss auf Seiten B passieren, wenn A ändert.
Wenn wir so eine Aufrufbeziehung haben, dann ist es natürlich so,
dass der Aufrufer eine bestimmte Sache erwartet. Ja,
wenn die Schnittsteuer aber gut gestaltet ist,
sind da bei diesen Sachen, die man erwartet,
technischen Details dabei, das heißt, die technischen Details sind entkoppelt,
dann ist es der Änderungsaufwand gering.
Bei dem Ereignis weiß man es einfach nicht. Da hängt
immer davon ab, was für eine Reaktion notwendig ist.
Ja, und beim Signal kann man auch das schlecht aufgrund
des Signals sagen. Wir wollen eine Lösung finden,
die sich breit einwenden lässt und das ist das Gegenteil,
das ist das Charakteristikum von Entwurfsmuskeln, Entwurfsmusters sind Lösungen für wiederkehrende Probleme.
Und dieses wiederkehrende Problem, was wir hier brauchen, ist eine Beziehung zwischen Dingen.
Wir werden gleich mal anschauen, dass wir die in faires Werkzeug brauchen.
Und zwar eine 1-zu-N-Beziehung. Einer hat eine Beziehung zu vielen,
sodass ein Änderung des Zustands von diesem einen dazu führt,
dass aller n-abhängigen Objekte benachrichtigt werden, aktualisiert werden.
Das wäre eine gute Sache. Ja, wir wollen das erreichen. So,
und das genau, was wir erreichen wollen, ist zwischen Kontenservice,
der Kundenservice ist etwas, der solche Materialien, in dem Fall das Konto bearbeitet.
Wir haben das schon von eben uns sicherlich alle gemerkt,
Konto ist das Fachliche, der fachliche Gegenstände, das Material,
ja, und da kann ich den Kundenbestand ergänzen,
ich kann Kunden eines Kunden bewerten,
alle Kunden der Bank oder so weiter, Vergünstigung,
besonders Sachen, den aktuellen Kontumstand, eine Prüfung,
obgültig und monatliche Kunde Führungsgebühren berechnen.
Wir wollen uns mit dem letzten Punkt hier mal beschäftigen und wollen mal anschauen,
was könnte so ein Kontoservice tun. Grundsätzlich hatten wir gesagt,
ein Werkzeug besteht aus zwei Teilen und Konto und Werkzeuge und Service wiederum sind zwei getrennte Teile,
die irgendwie zusammenarbeiten aus Sicht des Benutzers, ist,
dass ein Werkzeug, ja, aber es besteht aus das Werkzeugmachtrückgriff auf,
dass auf den Service, ja, und der Kundenservice,
das Kundenwerke benutzt in dem Fall, den konnten Service.
Und gleichzeitig soll natürlich das Werkzeug, sie erinnern sich,
Werkzeug ist die Benutzer, hat die Benutzerschnittstellen zum Kunden,
das Werkzeug soll den Kunden informieren,
wenn etwas geändert wird.
Das heißt, es muss hier
auch einen Rückweg geben
Und das würde so sein, zum Beispiel
das Kontenwerkzeug macht irgendwie, es ist nicht mehr Student.
Ja, und dann rechnet der Kundenservice die neue Gebührensumme,
vielleicht für alle Kunden der Bank. Und dann zeigt es,
das Kundenwerkzeug, die Gebührensumme der Bank aktuell an.
Das wäre ja erst mal so, dass der übliche Ablauf,
ja, das Problem ist, dass wir,
dass wir diese Sache hier als Hin- und als Rückbeziehung haben.
Also der Kundenservice muss wissen, wo schickt er das
denn hin
Vorher gehende Bild, ja, also der Kundenservice schickt hier etwas hin. Der schickt hier etwas hin,
wir sehen diese durchgezogene Linie, das ist eine Nachricht,
die gesendet wird mit einem Parameter oder wenn sie wollen,
als Methodenaufrufe zu formulieren, ja,
da muss man die Referenz auf Kundenservice,
Kundenservice haben und der muss die Referenz auf Kundenwerkzeug haben,
eine bidirektionale Beziehung zwischen beiden.
Ja, und das ist hier durch diese Pfeile dargestellt,
der eine Kind, den einen, der andere kennt,
den anderen, sie kennen sich einander und das sind benutzt Beziehungen,
die sind zyklisch.
Ja,
worin besteht das Problem
Das Problem besteht darin, dass der eine aktualisiertes Eindruck und
so weiter und die aktualisieren immer lustig drumherum.
Jeder sagt, es ist gerade was geschrieben worden, super,
da muss ich ja zurückinformieren und der meint, oh,
ich habe eine Information gekriegt, da muss ich ja schreiben.
Und dann sind die ständig am Aktualisieren und es hört nie auf.
Das wäre, das wäre die eine Variante, die schlecht ist.
Das zweite ist, wenn wir eine Weiterentwicklung der Software vornehmen,
eine Softwareveränderung vornehmen, dann,
und der hängt von dem ab und der hängt von dem ab,
dann müssen wir das beide gleichzeitig voneinander abgestimmt tun
Sie werden sagen, kein Thema,
spiele ich halt ein Paket ein, was beides enthält.
Und dann macht beides gleichzeitig. Das ist richtig. Aber
wenn Sie in einem wirklich großen System sind, dann,
das war, glaube ich, hier,
wo ich euch hier foliotreffe, ja, genau das hier.
Wenn Sie sich vorstellen, hier drin gibt es welche,
die hängen von den anderen ab, dann müssen Sie,
und die hängen vielfältig voneinander ab, dann wird das richtig schwierig,
das darzustellen.
Das wäre das für den Versionsupdate und für das Testen.
Ich kann nicht den testen, ohne den zu haben,
weil er liefert ja was zurück.
Ich rufe den auf und liefe was zurück
Und andersrum auch. Das heißt, beim Testen habe ich keine kleinen Tests,
kann ich keine Jüne-Tests machen und kann ich die Sachen voneinander entkoppeln.
Damit haben wir gleich die Antwort auf die Frage 9. Worin
bestehen die Nachteile zyklischer benutzt Beziehungen? So, wie können wir
diese Zyklen auflösen? Zyklen könnten wir so auflösen,
indem wir sagen, wir lassen den Rückweg weg.
Wir machen einfach das so, dass der Kundenservice Also der Kunde,
das Kundenwerkzeug stößt Veränderungen ein, ja,
ruft etwas auf und dann können wir direkt immer abfragen,
was passiert denn da?
Also wir fragen so quasi jeder zehn Sekunden nach,
Kundenservice hat sich irgendwas getan.
Kundenservice hat sich irgendwo was getan. Kundenservice hat sich irgendwo
was getan. Und damit kriegen wir ständig mit,
mit diesem maximal zehn Sekunden Verzögerung, wie häufig,
ob sich was geändert hat.
Das ist, wird er so aussehen,
wir haben das jetzt hier mal als Ablauf gestellt,
nebenbei merkt,
das ist das Sequenz
Aventsdiagramm der OML im Englischen Message Sequence Chart,
aber man kann das induitiv auch vielleicht so verstehen,
was wir hier haben, diese gestrichene Linie,
ist die Zeitleiste von oben nach unten.
Ja, und das Kundenwerkzeug ist ja,
wenn das hier breit ist, ist das eher aktiv.
Hier ist es das aktiv, das aktiv, das aktiv in
dieser Kasten her. Das ist einfach nur eine Notiz,
ist nur ein Text, den ich hier dran gehängt habe.
Also eigentlich die wirklichen Elemente sind diese Linie,
diese Lebenslinie und die aktiven Bereiche und Nachrichten hin und her geschickt werden.
So, und hier wäre es jetzt so,
das könnte jetzt so sein, ja,
vom Kundenwerkzeug hatten wir jetzt Einer ist nicht mehr Student.
Der muss also jetzt Gebühren bezahlen. Und das wird hier aktualisiert.
Ja, und fertig. Weiter machen wir nichts. Aber
dann haben wir dieses regelmäßige, berechnet die Gebührensumme und lassen uns die geben für alle.
Denn aktuell sehen wir, wie die dastehen, für die alle konnten.
Und dann machen wir vielleicht wieder, berechne Gebührensumme oder gib alle Kunden.
Und immer wieder, und immer wieder das Ganze, diese beiden Aufrufe,
um die Daten, die wir anzeigen, zu aktualisieren.
Und wir machen alle Updates, machen wir immer wieder.
Und das hilft uns. Wir haben eine aktuelle Information
Das Ganze hat, ist wirklich,
also hier stehen es nochmal so, ja,
wir stößen mit der Aktualisierung an und wir können den Zustand direkt zurückbekommen.
Der Name dafür ist Polling, wir fragen das Ganze ab,
die ständige Abfrage. Und das ist tatsächlich eine gute Lösung,
weil wir haben keinen Zyklus mehr.
Wir brauchen diese Verbindung, dass der Kundenservice,
das Kundenwerkzeug erkennt, das brauchen wir nicht mehr.
Wir können andersrum von Kundenreaktionen immer abrufen.
Und das ist wunderbar. Es gibt ein Aber und
das Aber steht hier
unten drunter
Wenn wir, ich hatte gerade das Beispiel alle zehn Sekunden,
da kann es maximal zehn Sekunden Verzögerung geben,
bis wir die aktuelle Information haben.
Weil wenn es gerade passiert ist,
gerade hat sich etwas geändert und dann fragt man,
haben wir kurz vorher erst abgefragt, dann dauert es zehn Sekunden,
bis wir wieder die nächste Abfrage kommen.
Wenn wir das genauer haben wollen mit kürzerer Nachrichtigungsdauer,
da müssen wir häufiger pollen.
Da müssen wir dieses Polling sehr viel häufiger machen.
Und bis dahin, dass wir bei schneller Reaktionszeitfotos,
dass wir dann ständig Polling machen.
Und das ist natürlich etwas,
was viel Werbe produziert,
sage ich mal
So, jetzt dazu eine bessere Lösung zu machen.
Und das ist jetzt das Entwurfsmuster. Die Lösung für die
Aktualisierung von Abhängigen, die ich beobachten möchte. Und zwar,
das wird sie insgesamt im Kern nicht beunruhigen oder vor das Unsichern oder Überraschen,
das ist etwas, was sie schon tausendmal gesehen haben.
Wir haben es hier und dem Namen Publish Subscribe im Prinzip.
Publish, ich informiere über Zustandsänderungen, Subscribe,
ich trage meinen Interessenwunsch ein
Das könnte zum Beispiel, das kennen sie,
das machen sie bei Medienlisten so,
das machen sie bei Messengers so, die sagen, okay,
ich will alle informieren, wenn ich bei mir was Neues ist,
aber ich möchte auch informiert werden, wenn bei meinem,
was weiß ich, bei meiner Schwägerin oder bei meiner Motor oder auch bei meinem Kopffreund,
was passiert.
Ja, dann trage ich mich ein. Das ist das Publish Subscribe-Prinzip,
beim Publish melde ich Zustandsänderungen, per Signal, Achtung,
es ist das und das passiert und sende das an alle,
die sich dafür eingeschrieben haben, wie so eine Mailingliste,
wie so ein Newsletter.
Und ich trage mich ein, und bekomme das wieder.
Und das ist auch gut geeignet, wenn ich mehrere Beobachter habe.
Also in unserem Fall, nicht nur ein Werkzeug, was konnten,
die Kundenstand bewendet, sondern auch alle investierte Politik bewertet.
Und eins, was Prämien für Mitarbeiter berechnet. Warum nicht?
Sie können alle auf den gleichen Kundenzustand zugreifen und haben jeweils etwas,
wo sich die Benachrichtigungen rausgeht und wo sie reingehen,
um den aktuellen Stand sich zu holen.
Wunderbar. Das ist die Verantwortung auf die Frage,
mir wieder unterschiedlichen Struktur von Polling und Beobachtern
muss noch Frage
So, jetzt das Entwurfsmuster. Ich hatte schon vorher gesagt,
Entwurfsmuster sind die wiederkehrenden Lösungen, es sind die Lösungen,
auf wiederkehrende Probleme und man beschreibt deswegen,
was ist das Ziel, was ist der Anwendungsbereich.
Diese Frage haben wir hier zwar durchgestrichen, was ist das Entwurfsmuster,
mit dem ist eine Definition, diese tischstrukturelle Text,
deswegen fragt man das jetzt nicht hier ab,
aber Ziele im Anwendungsbereich, das wäre Frage 13,
die wir hier haben.
Also die Ziele sind da rein,
der Ziel besteht darin, dass wir Änderungen synchronisieren,
dass wir in Überänderungen informieren und dass dabei gleichzeitig keine doppelte Abhängigkeit sein muss.
Also derjenige, der daran interessiert ist, der muss mir
nicht bekannt sein. So, das kann man gut anwenden,
wenn man die Konsistenz sicherstellen will, wenn man wenig Kopplungen haben will.
Man darf durchaus mehrere Aspekte haben, die eine Änderung betreffen.
Da kann man ja noch sagen, okay,
es gibt unterschiedliche Änderungen, Signale. Und es ist klar,
dass nur der Beobachter etwas tut, der andere tut nichts.
Wir schauen uns die Struktur an. Das ist auch gleich
die nächste Frage hier. Struktur in Frage 12,
Struktur und Dynamik. Wir fangen jetzt mal an mit der
Ja, das war falsch. Schöne Frage, genau, hier war die Struktur.
Ja, und zwar gibt es grundsätzlich Beobachter und beobachtbar.
Ich habe es mal fett geschrieben, damit wir den Unterschied deutlich sehen.
Also die Grundelemente dieses Beobachtermusters, Beobachter und beobachtbar.
Das ist beobachtbar, wäre zum Beispiel bei uns jetzt der Counter-Service,
den wir, als das ist eine abstrakte Klasse.
Und der Counten-Service ist davon abgeleitet, eine konkrete Klasse.
Sie erinnern sich vielleicht was, was das Besondere ist,
bei abstrakten und konkreten Klassen.
Die abstrakte Klasse bringt eine Verpflichtung mit sich
Was für eine Verpflichtung hängt sie denn mit sich? Schauen wir uns das an.
Sie sind dran? Kurzes Verraten, bitte? Ja,
sie bringt die Verpflichtung mit sich, dass die Methoden,
die hier genannt sind, hier implementiert werden.
Weil hier sind sie ohne Quelltext, ohne Buddy, ohne Implementation. So,
das heißt, viele Beobachterinnen zugemeldete Änderungen sind Nachrichten,
die hier nicht aufgerufen werden können, die erst aufgerufen werden können,
Mensch, eine konkrete, runterklasse,
mit Exemplaren haben
So, und der Beobachter,
das Beobachtbare wäre in dem Fall zum Beispiel der Kuntoservice,
kann beobachtet werden von, in unserem Fall von Werkzeugen.
Ja, und da haben wir verschiedene Werkzeuge und damit die
jeweils auch die Möglichkeit haben, das konkret zu implementieren.
Ist das hier so gemacht, dass das das Interface ist?
Also auch eine Art abstrakte Klasse,
die keine Methodenimplementierung mit sich bringt und die haben jeweils eine eigene Methodenimplementierung,
die das macht,
was für ihre Situationen erforderlich ist
So, das Interface muss implementiert werden von jeder Klasse,
die etwas beobachten möchte, ja,
und wir haben dieses Publish Subscribe im Sinne von,
also das Subscribe schon mal, dadurch, dass man,
man kann sich registrieren, also der Beobachtbare kann sich hier registrieren,
ich registriere das hier drüben für ihre Beobachter hinzu und habe das,
bin hier eingetragen.
Gleichzeitig in die andere Richtung, melde Änderung und der Beachteränderung,
ich sende eine Änderung hierüber und alle,
die sich hier registriert haben,
bekommen das Änderungssignal
Anderen Seite das, was beobachtet wird,
das ist dann eine konkrete Unterklasse dieser abstrakten Klasse,
die der Erb davon und dieses Melde Änderung ist etwas,
was der dann implementiert.
Er hat dann konkret eine konkrete Änderung, die er machen muss.
So, soweit, das war die Struktur,
jetzt nochmal, wie sieht das im Quelltext aus?
Also hier haben wir diese Informationen, beachtet die Änderung,
das sendet er an alle, die hier dieses Interface implementiert haben.
Das hat mir im vorhergehenden Bild hier,
ja, an diese drei sendet er das
Und dass sie zu Ost ist, einfach eine Schleife hat
und sendet an alle Beobachter, die sich registriert haben.
Bitte mach das mal. Und hier nach der Änderung,
dadurch ist dein Implementierung, was dann tatsächlich passieren sollte,
wenn deine Erinnerung kommt, die mich interessiert.
Muss ich in beiden Biagramm neu zeichnen? Muss ich Werten
in der Tabelle verändern? Oder muss ich einfach gar nichts
tun, weil es gerade diese Änderung mich nicht interessiert?
Und die beobachtbare Klasse ist eine Unterklasse von dieser Seite,
eine beobachtbare Klasse, die hat natürlich diese ganzen Daten
So, wie sieht denn das aus?
Hier gibt es zum Beispiel so irgendwas in der Abfrage,
gibt in diesem Beacht der Änderungen, ist zum Beispiel drin,
gib mir den Zustand, zeige den Zustand.
Was für uns jetzt interessant ist, ist, dass wir
diese Zyklen tatsächlich vermieden haben. Wir haben es vermieden,
dass der eine der anderen oder andere den einen kennt,
das Kundenwerkzeug kennt den Kundenservice.
Also, das Kundenwerkzeug ist jetzt hier drüben. Moment,
wir haben ein bisschen zurück, wo wir das noch sehen können.
Das Kundenwerkzeug ist ja auf der Seite hier
Und das Kundenwerkzeug kennt seinen Service und der Service kennt,
aber umgekehrt, das Kundenwerkzeug nicht.
Also es gibt ja keinen Aufruf hier rüber. So,
sondern nur über das Interface-Beobachter hier oben. Nur über das Interface
habe ich diese Information und kann da zugreifen. Soweit die Struktur,
ich gehe nochmal zu der Frage und vorne hin,
wir hatten ja hier die Frage zur Struktur
und jetzt kommen wir zur Dynamik
Die Dynamik, wir sehen das wieder am Sequenzdiagramm mit dieser Lebenslinie.
Also oben, wir haben zu Anfang ein Kundenwerkzeug,
das investiert das Interface und der Kundenservice, der implementiert das,
was bei beobachtbar steht, indem man davon hört.
Das ist abstrakte Klasse, muss aber es auch implementieren. So,
und jetzt, was wir hier zu sehen bei dem,
wir haben zwei solche Bilder, der erste Schritt ist,
ich registriere mich, das Registrieren passiert so,
dass das Kundenwerkzeug sagt, Achtung, ich möchte informiert werden,
ab sofort überall Änderungen Und dann macht der Kundenservice ja super,
kein Problem.
Ich stelle dich mal in eine Liste, du wusstest jedes Mal eine Information kriegen.
Er packt den also in die Liste. Der zweite Teil,
den wir uns anschauen, ist genau dieses eine Information geben. Ja,
also hier ist bei irgendwas passiert, in dem Fall,
jemand ist nicht mehr Student, ja, so das Kundenservice,
der Kundenservice gibt diese Information weiter und das Kundenwerkzeug,
was jetzt das Einzige ist,
was alle Kunden kennt,
berechnet die gesamten Gebühren,
zeigt die an und gibt die
zurück zum Kundenwerkzeug
Und das wäre die Möglichkeit, dass wir hier dieses Berechnen tun können.
Und ja, genau, das war es schon eigentlich,
um zu sagen, ja, wir haben hier eine aktive Abfrage.
Berechnet der Gebührensumme und dann kommt das irgendwie zurück.
Nochmal im Überblick und auch weiterführen. Wir hatten also
das Polling-Modell dargestellt, weil wir gesagt haben,
das andere funktioniert nicht wirklich und wir haben hier noch weitere Mechanismen.
Ja, wir haben das Pull-Modell,
wo man sich etwas holt, Pull und Push,
Pull ist holen,
Push ist wegschreiben
Das gibt es auch als Bush, dass man das,
wie gesagt, weiterführende Lösung und es gibt noch eine
hybride Lösung dazu und hier können Sie mehr dazu lesen.
Damit haben wir Ihnen das Entwurfsmusterbeobachter dargestellt. Ich gehe nochmal
zurück. Im Kern besteht es daraus, dass wir also
ein Interface haben, Beobachter und eine abstrakte Klasse beobachtbar.
Die steht für alles, was ich irgendwie beobachten wollen kann.
Und ihr drüben, das steht dafür,
für irgendwelche Werkzeuge, die diese Informationen gerne hätten
Die müssen dann hier von erben und die müssen hier von
einer Demons eine Interface invemitieren.
Und die müssen hier von ihr auch mit einem von selber
aus.
Soweit dazu