Im dritten Abschnitt dieser Vorlesung wollen wir uns mit einem anderen,
aber verwandten Aspekt beschäftigen. Und als Einstieg habe ich
hier nochmal die Entwurfsregeln gezeigt mit diesen vier Bestandteilen.
Wir werden uns damit beschäftigen,
wie man die Kopplung zwischen diesen Teilen hinbekommt und dabei gleichzeitig
ein Entwurfsmuster einführen und sie mit diesem Konzept vertraut machen,
wiederverwendbare, etablierte Lösungen einzusetzen.
Es wird also darum gehen, wie wir Werkzeug und Service,
was wir hier in dieser Folge sehen,
koppeln können
Ja, als Einstieg zeige ich Ihnen so ein nettes Bild.
Reale Systeme sind etwas größer als unsere Mediathek und etwas größer
als nur so ein Kontosystem.
Und wir haben viele Teile in diesem System.
Und zwischen diesen vielen Teilen gibt es Benutzungsbeziehungen. Diese Pfeile
hier können durchaus Benutzungsbeziehungen sein. Und das bedeutet also,
hier haben wir eins, was wir ändern,
oder es kommt ganz häufig vor, dass sich Teile ändern müssen.
Wir haben solche Änderungen, weil Gesetze sich ändern,
weil die nur sich etwas anderes vorstellen. Oder einfach nur,
weil die Abläufe in einer Firma oder in einem Geschäftsprozess sich ändern.
Und dann muss ausgehend von einer Änderung an diesem Teil dieses,
dieses, dieses, dieses ganz viele andere geändert werden.
Und bei jeder Änderung können Fehler passieren,
weil man das System nicht ganz komplett versteht, das wollen wir vermeiden.
Wir wollen vermeiden, dass Änderungen sich zu sehr ausbreiten.
Und diese Änderungen resultieren hier durch ganz viele benutzt Beziehungen.
Aber natürlich brauchen wir Beziehungen, damit die Dinge zusammenarbeiten.
Und dafür wollen wir
eine Lösung einführen
Zunächst erst mal etwas Grundsätzliches, wie kann so etwas ablaufen?
Wie kann so etwas aussehen? Wie kann so eine Kopplung
zwischen Teilen passieren? Zunächst können wir erst mal sagen,
es gibt drei unterschiedliche Arten. Ja, wir können einen Aufruf machen,
das ist doch was, die Programmiersprache grundsätzlich macht.
Und in Java sieht das so aus,
da gibt es diese Assoziationsbeziehungen im UML-Diagramm eine einfache Linie.
Man kennt A, kennt B und man ruft die einfach
auf.
Dann gibt es noch Ereignisse
Auch das wäre irgendwo eine Möglichkeit der Verbindung zwischen A und B.
Ein Ereignis wird von A ein B gesendet und man schaut mal,
was da passiert. Also so wie sie senden einen Brief,
zum Beispiel an eine Behörde. Sie kriegen vielleicht, ja,
man erwartet eigentlich eine Eingangsbestätigung, aber nicht unbedingt passiert was.
Dazu gibt es nicht wirklich ein Konzept in Java,
aber es wäre eine Möglichkeit, das irgendwie nachzubilden.
Und dann gibt es noch die Möglichkeit,
ein Signal zu senden
Broadcast ist das Wort für Rundfunk, ja,
also ich sende eine Nachricht aus an alle, die irgendwie das empfangen wollen,
ja, und damit kann ich auch eine Aktion erreichen,
etwas auslösen, ja, man könnte sowas auch machen,
in Java irgendwie nachbilden, wenn man ein Netzwerksystem hätte.
So, also diese drei grundsätzlichen Möglichkeiten gibt es erstmal und wir wollen überlegen,
das Problem war ja der Änderungsaufwand, ja,
wie hoch ist der Änderungsaufwand bei dem bei dem Abhängigen,
wenn wir das A ändern. Und wenn wir den Aufruf verwenden,
ja, dann würde das, wenn wir delegieren,
durch Delegation das realisieren, würde das nicht so groß sein,
weil wir dann schon, wenn wir versuchen,
gute Entkopplungen zu erreichen, ja, bei dem Ereignis,
da weiß man es nicht, je nachdem,
wie es realisiert wird.
Und ihr, ja, prinzipiell sind die Empfänger anonym,
aber Sie müssen sich ja darauf einstellen, wenn da was anderes kommt.
Wenn im Radio, das Radiosystem jetzt umgestellt wird von UKW auf digitalen Rundfunk,
ja, da müssen sich alle neuen Radioempfänger kaufen.
Ja, also deswegen ist das, ja, es gibt schon noch Änderungen. So,
wir wollen jetzt für dieses Kopplungsproblem, das,
was wir mit dem schönen Bild,
mit den vielen Beziehungen hatten, wollen wir versuchen,
eine verbesserte Lösung zu finden und das versuchen wir und da bei der Gelegenheit wollen wir drüber sprechen,
was ein Dorfsmuster ist.
Ja, die Aufgabe ist also,
wir wollen eine Beziehung zwischen einen und vielen erreichen, ja,
sodass die Änderungen weitergegeben werden irgendwie zu einer Aktualisierung führen.
Und das wollen wir so erreichen, dass eine geringere Änderungsaufwand passiert.
Wir machen das zwischen Service und Werkzeug. Ich habe mal hier aufgestellt,
was alles passieren könnte, wenn wir im System Konto und Kunde, ja, also das Kontenwerden von einer Bank verwaltet. Die Bank hat für Konten alle möglichen Services,
ja, und ich habe mal hier, natürlich gibt es,
dass man konnte, Kunde hat, dass man den Kunden löscht,
dass man alle Konten bekommt, und dass man,
es gibt in unserer Bank für Studenten einen besonderen Bonus,
die müssen keine Gebühren bezahlen, kostenlose Gebührung,
Kontoführung und diesen Status verliert man natürlich ja irgendwann mal,
weil die Bank will ja auch Geld verdienen, ja,
und da gibt es natürlich einen Kontostand und ist das wirklich registriert und wir wollen wissen,
wie viele Gebühreneinnahmen haben wir denn,
weil die Bank muss ja auch von was leben.
Irgendjemand muss ja die Miete bezahlen und die Gehälter. So,
also das ist nur so zur Illustration,
das wird unser Beispiel sein und wir wollen dieses Kundenwerkzeug,
was es nur einmal gibt für alle Kunden,
das wollen wir irgendwie so einbinden,
also wir hatten gerade vorher gesehen, den Service,
der wird vom Werkzeug aufgerufen und drüber ist der Benutzer,
der ja eigentlich die Aktion startet.
Und was wir erreichen wollen, ist, dass der Kontenservice
aber gleichzeitig das Resultat irgendwie weiterleitet. Wir hatten,
wir hatten uns gemerkt, interaktive Systeme, ja,
das Werkzeug ist das, was die Interaktion mit dem Benutzer macht,
also nicht nur in diese Richtung,
sondern auch die Informationen entgegennehmen.
Das heißt, wir brauchen auch was in diese Richtung
Ja, und das könnten wir machen jeweils,
nicht nur wie hier oben eine Benutzungsbeziehung,
sondern hier auch eine Benutzungsbeziehung, einen Aufruf halt.
So, wenn wir das tun, könne das so aussehen,
ja, also wir machen jetzt mal diesen Studentenstatus und die Gebührensumme insgesamt der Bank.
Im Kundenwerkzeug wird irgendjemand verliert seinen Studentenstatus, ja,
und dann ist die Gebührensumme der Bank insgesamt,
wird neu berechnet und die Bank wird,
das Management kriegt die Information, die Gebührensumme ist jetzt diese Zahl.
Ja, so, und dann kann man
die Gebührensumme der Bank anzeigen
Das wäre erst mal soweit denkbar. Ja,
soweit alles gut, oder wir haben ein kleines Problem.
Und zwar das Problem Zyklen. Diese Zyklen wollen wir versuchen zu vermeiden,
weil die haben große Nachteile. Natürlich wird es funktionieren,
ja, aber funktionieren allein ist kein Argument,
weil wir, wenn wir zu viele Nachteile dabei haben.
Und das Nachteil ist zum einen,
wir haben die Gefahr, so eine Endlosschleife, ja,
also der eine arktisiert den anderen und der an Bord gemerkt,
oh,
es hat sich ja was geändert,
ich muss wieder aufrufen
Aber noch schwieriger ist es, wenn wir Änderungen durchführen.
Wenn wir ein Update machen,
weil wir einen Fehler behoben haben oder eine neue Version brauchen oder irgendwas,
wenn die beiden voneinander abhängen, müssen wir sie immer gleichzeitig aktualisieren.
Und beim Testen ist es genauso. Ich kann nicht
das eine testen und das andere weglassen. Ich muss sie
immer beide testen, weil sie brauchen sie beide.
Und wenn wir da viele Systeme haben, große Systeme haben,
dann ist das relativ schwierig, dieses Testen und das Aktualisieren hinzukriegen.
Wir wollen das auf kleine Einheiten beschränkt haben.
So, deswegen sind Zyklen möglichst zu vermeiden
Wie können wir das tun? Natürlich wäre das so,
dass wir diesen Fall, wollen wir nicht.
Wir wollen versuchen, dass es nur in eine Richtung geht.
Im Prinzip würde die andere auch gehen, aber jedenfalls nur in eine.
So, und wir können, wir haben jetzt die erste Idee,
die wir verfolgen, ich werde eigentlich zwei Ideen vorstellen.
Die erste Idee ist die, dass wir eine Aktualisierung einstoßen. Das Werkzeug sagt,
ja, hier hat sich was geändert, ja, ruft den Konten,
da konnten Service auf, also diesen Aufruf gibt es,
ja, und dann wird das, ruft der Kontenservice,
kümmert sich drum, was denn da alles passieren muss.
Ja, berechnet das und das Kundenwerkzeug fragt immer nach,
hat sich denn was geändert?
Ja, und dadurch könnten wir die Aktualisierung hier oben,
wir haben den Benutzer jetzt hier nicht gezeigt, den Benutzer jeweils immer darstellen.
Dieser ständige Abfrage hat sich etwas geändert, hat sich was geändert,
hat sich was geändert, wie bezeichnen wir als Polling?
Wir schauen uns das mal im Sequenzdiagramm an. Sie ändern
sich Sequenzdiagramm. Hatten wir schon mal. Das bedeutet,
hier oben sind die Beteiligten Hier diese Linie,
die gestrichelte, ist die Lebenslinie von oben nach unten.
Und diese schmalen Kästen heißt aktiver Bereich. Da tut man etwas.
Also das Kontenwerkzeug löscht diesen Kundenstatus. Da konnten Service,
trägt den aus. Und dann berechnen Ruf des Kundenwerkzeugs,
also wie hoch sind denn jetzt unsere Gebühren,
die wir bekommen? Könnten Service, rechnet den aus,
schickt den um und zeigt den an.
Und dann könnte man noch weitere Sachen machen, irgend sowas.
Aber man müsste jedes Mal wieder nachfragen,
hat sich was geändert, hat sich was geändert,
hat sich
was geändert
Also davon ausgehen, dass in der großen Bank ganz viele Leute,
die Kunden sind, müssten wir ganz häufig nachfragen.
Und deswegen nach jedem Aufruf muss ich alles aktualisieren,
was sich da geändert hat.
Das könnte, das braucht einiges an Rechenleistungen, Ressourcen.
So, softwaretechnisch ist das Polling eine super Lösung. Ja,
wir haben wirklich, es erreicht, dass es keinen Rückweg gibt,
weil wir nur die Abfragen von dieser Richtung machen.
Ja, aber dieses Polling beschäftigt den Quantenservice,
es das Werkzeug muss ständig
auch dieses Polling machen
Das ist also eine Lösung, ja, ja, füllt das,
sie ist sauber im Sinne von, wir haben keine Zyklen,
aber sie hat einige andere Nachteile oder einen anderen Nachteil.
Und wir wollen jetzt einen anderen, ein anderes Schema einführen,
und zwar, dass das benachrichtigten Beobachters.
Damit sind wir, erstatten wir mit dem Beobachtermuster.
Ein wichtiges Prinzip dabei ist das Publish-Subscribe-Prinzip, ja,
und das ist das, was ich zuerst erklären möchte.
Es ist auch eine Lösung für diesen Hin- und Rückweg.
Und zwar, dass wir uns Nachrichten bereit verbreiten über
das Publish und mal uns dafür einschreiben mit Subscribe.
So ähnlich kennen Sie das schon bei Newslettern. Ja,
Sie melden sich an für einen Newsletter und dann kriegen Sie jedes Mal,
wenn es eine neue Information gibt, bekommen Sie die.
Und Sie können die auch wieder abbestellen.
Auf diese Weise sind Sie immer informiert,
aber der Sender hat mich wirklich eine enge Beziehung mit Ihnen.
Klar, er kann auch nachschauen, wer ist denn da gerade alles registriert?
Liest überhaupt jemand das Zeug, was ich so sende?
Aber das wäre das Prinzip. Also das Publish-Zustandsänderungen werden jeweils
vom Service gemeldet und das Kundenwerkzeug kann deswegen die Informationen bekommen.
Ja, also deswegen wird das Voraussetzung ist, dass man
bekannt ist. Und dieses Bekanntmachen, sich bekannt machen,
eintragen, passiert durch das Subscribe.
Wir haben dabei gleich noch einen weiteren Effekt. Wir können
mehrere Werkzeuge bedienen. Das ist das ja immer, wofür wir ausgehen.
Wir haben nicht so ein ganz einfaches System, sondern mehrere Werkzeuge.
Zum Beispiel, wir haben hier nicht nur das Werkzeug,
was die Kundenübersicht bildet,
sondern auch noch,
wo Prämien berechnet werden,
Premien für den Kunden
Premien für irgendwelche Mitarbeiterwerber oder sowas.
Oder Werkzeuge, die die Bonität eines Kunden berechnen.
Auch die können in gleicher Weise vom Conservice bedient werden.
Die können auch Aktualisierung kriegen. Und die können dann
selbst entscheiden, brauche ich die Aktualisierung oder nicht.
In allen Fällen haben wir nicht diese Abhängigkeit.
Wenn wir hier mit den klassischen Benutzbeziehungen arbeiten würden,
würde wir bei jeder Änderung, die es vielleicht hier gibt,
müssten wir Kundenservice vielleicht ändern und dann müssten wir die anderen auch noch alle ändern.
Und da werden wir mit lauter Ändern nicht mehr
fertig von den Fehlermöglichkeiten ganz zu schweigen.
So, schauen wir uns das an,
wie das funktionieren kann
Das Prinzip dahinter bezeichnen wir als Entwurfsmuster. Ein Entwurfsmuster steht
für eine wiederkehrende Lösung, die wir mehrfach einsetzen können,
die angepasst wird auf die Situation.
Diese Lösung ist deswegen nicht konkret, sie ist nicht richtig ablauffähig,
es kommt nicht mit Quellcode wie ein Softwarebaustein oder ein Produkt,
was man kaufen kann, sondern sie kommt als Lösungsschema.
Dieses Lösungsschema hat natürlich den Vorteil,
dass es diese Anpassbarkeit noch hat und den Nachteil,
man muss etwas tun
Wir beschauen zunächst erst mal an, was es denn tut.
Also das Ziel steht hier unter Zweck, synchronisieren,
eines zentral verwalteten Gegenstandssubjekts steht hier,
das ist dieses beobachtbare Objekt von mehreren, mit mehreren Beobachtern.
Und die Beobachter, die müssen nicht unbedingt bekannt sein,
es reicht uns einfach nur, dass die die Informationen bekommen.
Und was wir erreichen wollen, wir wollen die Konsistenz sichern,
wir wollen geringe Kopplung erreichen. Und was wir aber ermöglichen können durchaus,
ist, dass es verschiedene Aspekte von Änderungen geben kann.
Und die Reaktion durch den Beobachter erfolgen kann.
Soweit schauen wir uns an, wie das genau aussieht.
Wir führen als Begriff ein Beobachter unbeobachtbar. Beobachter sind die
Werkzeuge und beobachtbar ist der Service, der die Daten liefert,
der die Berechnungen durchführt. Wir machen das so,
dass wir hier für die mehreren Beobachter ein Interface bilden,
in der Face erinnern sich, eine abstrakte ein abstraktes Gebilde in Java,
was Vorgaben macht für das Verhalten.
Es muss noch implementiert werden, das heißt, es sind nur abstrakte Methoden.
Und hierfür den Kundenservice machen wir auch etwas Abstraktes.
Hier nehmen wir eine abstrakte Klasse. Die abstrakte Klasse beobachtbar,
ist dann die Oberklasse für konkrete Services, die konkreten Services.
Also wir können auch mehrere Services nach dem Schema bauen.
Das ist das Wiederverwendbare an dieser Lösung. Und die sind
hier registriert und der Beobachter kann dann deswegen die Informationen weiterleiten.
So, das Interface muss implementiert werden von jeder Klasse, die etwas beobachten möchte.
Ja, und hier gibt es zunächst erst mal dieses Fügebeobachter hinzu. Das heißt,
ich registriere mich und beachte eine Änderung,
ich führe eine, ich kümmere mich drum,
was denn da passiert ist, hole mir die Daten,
schaue, ob ich überhaupt etwas tun muss,
aufgrund dieser Soldaten, ob in meinen Darstellungen,
die ich mit dem Kunden dem Benutzer zeige,
ob da etwas zu ändern ist und wenn ja,
führe ich
diese Änderung durch
Die Klasse beobachtbar ist die Oberklasse für alles,
was so ein Subjekt sein muss, was beobachtbar ist.
Und es meldet die Benachrichtigung über eine Änderung, Änderung die Soldaten.
So, wie sieht das aus? Wir haben also das Interface,
wir haben die abstrakte Klasse und ganz konkret ein konkreter Beobachter,
also unser Werkzeug, implementiert dieses Interface eine beobachtbare Klasse,
erbt von dieser Oberklasse.
Und die haben dann
die Beziehung miteinander
Und wichtig ist ja vor allen Dingen,
wenn eine Änderung passiert ist, ja,
dann muss ich eine Reaktion geben und diese Reaktion passiert in einer Methode,
in dieser Methode, beachte Änderung, die im Interface nur abstrakt ist.
Da wird, hat der konkrete Implem-Beobachter eine konkrete Realisierung für.
So, das könnte zum Beispiel sein, wenn wir,
der Kundenservice hat irgendwie den,
den Zustand des Kontos auf Student geändert,
ja,
dann kann ich
den abfragen
So, und jetzt prüfen wir nochmal, ist denn das mit den Beziehungen,
wie ist denn das mit den Beziehungen gedacht?
Ist das in beiden Richtungen wirklich ein Informationsaustausch und wie sieht das mit den Abhängigkeiten aus? Ja,
die Informationsaustausch haben wir dadurch, dass es das Signal gibt,
ja, und das Signal, es ist eine Änderung passiert und die,
nämlich hier über Meldeänderung, ja,
und die Information über die Daten passiert darüber, dass wir uns den Zustand geben lassen.
Dabei haben wir Abhängigkeiten nicht in beide Richtungen, das Werkzeug kennt den Kontenservice. Also das ist hier das Werkzeug,
kennt den Service, das ist diese Beziehung,
aber der Service kennt das Werkzeug nicht, nicht direkt,
sondern es kennt nur das Interface und hier gibt es nicht wirklich eine,
und im Interface ist keine Implementierung drin, das heißt,
hier gibt es nichts, wenn wir hier den Quellcode ändern,
dann müssen wir hier drüben nichts ändern,
weil den Quellcode kennt der Ehriger mich.
Ja, damit haben wir auch das erreicht nebenbei,
was Wann fordert für diese Beziehung zwischen den beiden Klassen?
Ich springe nochmal zurück zu dieser Übersichtsfolie mit den vier Klassen.
Das war die Nummer 19. Wir kommen gleich her zurück.
Also das Werkzeug hat nur einen Fall in diese Richtung.
Die anderen dürfen sich nicht kennen. Und das ist genau das,
was wir auch erreicht haben hier vom Werkzeug zum Service,
haben wir nur diese eine Richtung.
So, schauen wir uns mal an,
wie das im Ablauf passiert. Wir haben zwei Abläufe,
zunächst erstmal dieses sich eintragen, dieses richtig registrieren.
Und das Werkzeug sagt,
bitte informiere mich über geänderte Daten
Zum Service und fügt sich als Beobachter hinzu und trägt sich
bei der Kundenservice in die Liste der zu informierenden Beobachter ein.
Das ist zunächst erst mal nur so ein einfacher Aufruf.
Also nicht wirklich ein spannendes Sequenzdiagramm. Wenn eine Änderung passiert ist,
dann werden alle informiert, die Änderungen, die sich registriert haben.
Also zum Beispiel im Kundenwerkzeug hier dieses, was wir vorhin hatten mit dem Studentenstatus,
da verliert jemals ein Studentenstatus und der Kundenservice sagt jetzt allen,
sich registriert haben, allen Beobachtern, sagt er,
Achtung, es gab eine Änderung.
Und dann weiß das Kundenwerkzeug und nur dann, ja,
jetzt muss ich mal die Gebührensumme neu berechnen,
holt die Gebührensumme und kann die dann anzeigen.
Wir haben also hier diese Abfrage nur,
das eine Mal, wenn sich wirklich etwas geändert hat,
wir müssen nicht ständig nachfragen, hat sich was geändert,
hat sich was geändert, wie das bei dem Polling wäre.
Soweit erstmal zu dem Ablauf Es gibt natürlich auch Vor- und Nachteile.
Die Vorteile, ganz klar, das wollten wir erreichen,
wir wollten diese Entkopplung erreichen. Und damit erreichen wir Flexibilität,
Modularität und am Ende, dass wir weniger Änderungsaufwand haben,
weil sich die Änderungen nicht ausbreiten im System.
Wir erreichen auch, dass der Zustand des Gesamtsystems konsistent bleibt.
Konsistent im Sinne von jeder Änderung wird gleich irgendwo registriert.
Es passiert nicht, dass der eine Teil nicht das durchführt,
was der andere gemacht hat. Und was wir auch noch haben,
wir passen zu diesen, Man kann Systeme bauen,
die zu so übergeordneten Schemata-Schichtenmodellen passen, wie bei uns,
mit diesem Werkzeug und dem Service.
Die Forderung, das sollen wir in die eine Richtung gehen
, so was können wir hier gut erreichen.
Keine Vorteile ohne Nachteile. Der Nachteil könnte hier auch sein,
wenn wir komplexes System haben, mit ganz vielen Subjekten und mit ganz vielen Beobachtern.
Dann könnte es dazu kommen, dass der eine informiert den einen,
der Andreas aktuell ist, ist etwas anderes und so weiter.
Das ist da zu richtigen Kaskatenwellen und vielleicht sogar zu schwer
nachvollziehbaren Effekten kommen kann. Da muss man also vorsichtig sein,
welche Informationen man wohin weitergibt
Dann besteht prinzipiell die Gefahr, dass man es vergisst, einen Beobachter abzumelden.
Ja, also ich muss mich registrieren, erst mal wunderbar,
dann kriege ich alle Informationen, aber ich vergesse es, mich abzumelden.
Ist erst mal nicht so schlimm, wir haben ein bisschen mehr Aufwand,
auf Änderungen zu reagieren, aber es könnte passieren,
dass wir, wenn wir das Objekt nicht mehr brauchen,
dass dann in Java die Garbage Collection nicht funktioniert,
Garbage Collection, sie haben das schon mal gehört,
Elemente, Objekte werden aufgeräumt, werden aus dem Speicher entfernt,
wenn keiner mehr auf sie verweist.
Aber hier werden sie ja noch irgendwo registriert und deswegen weiß Java nicht,
das Java-Lauf-Zeitsystem nicht, das wird nicht mehr gebraucht.
Also wenn man das vergessen hat, gäbe es schon den Nachteil.
Und was wir auch noch sagen können in der Struktur,
wie wir sie hier gewählt haben, mit so einer Superklasse,
das ist, wir können ja immer nur einfach für Abo machen,
dann können wir diese Superklasse nicht mehr verwenden für etwas Fachliches.
Wir gehen mal zurück zu dieser Klassenstruktur, um das nochmal zu zeigen.
Ja, also hier, wir hatten ja hier eine Oberklasse,
die Services, die haben ja, die ist beobachtbar als Oberklasse.
Und wir haben das als abstrakte Klasse gebildet und damit können wir nicht mehr
eine abstrakte Oberklasse machen, zum Beispiel für irgendwelche Sachen,
die mit Konto zusammenhängen, damit Kundenservice von denen erbt.
Nein, Kundenservice muss jetzt von beobachtbar erben.
Allerdings dieser Nachteil ist nicht wirklich ein großer Nachteil.
Wir könnten das beheben, indem wir hier auch ein Interface machen.
So, wir schauen uns nochmal die Fragen an.
Die waren auf der Folie 33, ich hatte hier neue Fragen,
damit die völlig so weit zurückspringen müssen.
Die Nachteile zyklischer Benutzbeziehungen hatten wir erklärt, auf der Folie 41,
also hier, was ist denn der Nachteil,
dass wir Änderungen haben, insbesondere diese Änderungen,
dann uns Versionsupdates, Aktualisierungen schwer machen und das Testen schwer machen.
Die nächste Frage 10, Struktur und Dynamik des Beobachtermusters,
das war das, was wir hier mit diesen Klassen vorgestellt hatten.
Nein, das war es noch nicht. Wir haben es
noch eins weiter. Genau. Hier ging das los.
Also hier haben wir die Struktur erstmal vorgestellt und jetzt kam
die Dynamik.
Das war Struktur und Dynamik
Dann haben wir Vor- und Nachteile. Das war gerade das,
was wir eben nochmal gesehen haben. Die Ziele im Anwendungsbereich war,
als wir das vorgestellt haben, frohe Nachteile, die letzte Folie.
Polling und Beobachter muss dort gegenübergestellt haben wir auch,
dass Polling diese ständige Abfrage, das Beobachtermuster, über das Registrieren,
Aktualisierung nur dann, wenn wirklich eine Änderung passiert ist.
Und die Beziehungen, die waren in der Struktur mitenthalten.
Als letzte Folie habe ich noch eine Ergänzung mitgebracht.
Nein, hier noch eine weiter. Es gibt für diese Aktualisierungsmechanismen
tatsächlich unterschiedliche Mechanismen, Push und Pull kann man da machen.
Ich habe hier den Keks mitgebracht als Zeichen dafür,
dass es weiterführend ist. Hier gibt es auch eine interessante Seite,
die einen studiert, studieren, da mal gemacht hat,
der seine Ergebnisse hier eines Projekts dargestellt hat.
Es ist ganz gut aufbereitet. Ich würde sagen, alles,
was da steht, stimmt. Deswegen kann ich Ihnen das
gut empfehlen. Also wenn Sie sich für weiterführendes interessieren,
das selbst bauen wollen, dann sollten Sie sich noch informieren, was hier passiert.
Das ist also weiterführend, kommt nicht in der Prüfung dran.
Soweit sind wir damit durch. Ich hoffe,
dieses Beobachtermuster können Sie zu Ihrem eigenen Vorrat an Lösungen hinzufügen,
dass sie das mal einsetzen, wenn sie Entkopplung brauchen,
wenn sie Synchronisation brauchen.
Es kommt tatsächlich sehr häufig vor,
wir werden das finden, das ist relativ häufig
dieses Muster