Herzlich willkommen zur nächsten Vorlesung. Sie schließt inhaltlich an das an,
was wir in den letzten zwei Vorlesungen auch schon besprochen haben,
nämlich wie Software gestaltet wird.
Heute möchten wir uns mit dem Entwurf beschäftigen und wann ist Entwurf denn gut?
Dazu gibt es wieder Fragen. Das ist, das ist auf
der nächsten Folie. Da kommen wir dann nochmal dazu.
Doch zunächst möchte ich erstmal über gut sprechen. Zum,
wir streben natürlich nach hoher Qualität und hohe Qualität sieht erstmal mal so aus,
dass wir versuchen, das zu erreichen,
was der Auftraggeber von uns möchte.
Also wir möchten Eigenschaften erreichen. Welche dabei wichtig sind,
hängt sehr davon ab, welches Anwendungsgebiet die Software bedienen soll und welche Richtung es geht.
Es ist immer ganz gut, eine Norm zu verwenden,
weil die Begriffe dort beschrieben sind und viele Leute haben darüber
dem zugestimmt und ich führe deswegen hier mal die Norm für Software-Qualitätseigenschaften ein.
Das ist die ISO 25010. Wir gehen nicht weiter darauf ein
. Hier haben Sie die immerhin schon mal gesehen.
Diese Hauptkriterien sind hier oben genannt und Da gibt es noch eine zweite,
also es gibt einerseits die eigentliche, das eigentliche Softwarequalität,
das Softwareprodukt, das Softwaresystem und dann die Benutzung und uns für Software,
die geändert werden muss, ist die Wartbarkeit besonders wichtig.
Neben den anderen Eigenschaften, die für den Nutzer richtig sind,
wie nämlich, ob die Funktionalität passt, die Zuverlässigkeit,
wie sieht das mit der Performance und der Ressourcennutzung aus,
die Benutzbarkeit, Sicherheit, Kompatibilität,
die sind für den Benutzer richtig sichtbar und benutzt und bewirken eine bessere oder schlechtere Anwendbarkeit ist die Wartbarkeit und die Portabilität, vor allen Dingen für den Entwickler, von Bedeutung.
Und uns geht es vor allen Dingen darum, Änderungen zu vereinfachen,
diese Änderungen, von denen wir schon immer gesprochen haben,
dass sie ganz häufig auftreten.
Deswegen ist Maintainability für uns im Fokus der Aufwand für Änderungen.
Also wir gehen auf diese Kriterien jetzt hier nicht weiter ein im Einzelnen.
Sie sind hier mal angeführt, zum Beispiel,
ich habe schon gelegentlich eingeladen zu der Veranstaltung Softwaretechnik im vierten Fachsemester,
dort geht es noch genauer um diese Eigenschaften
Außerdem möchte ich noch mal einordnen oder überhaupt den Zusammenhang zwischen Entwurf und Modell veranschaulichen.
Warum benutzen wir hier Modelle? Ja, deswegen,
weil wir beim Entwurf von Problemraum zum Lösungsraum im Fall großer Systeme
nicht alles mit einmal im Blick haben können.
Wir möchten es vereinfachen und ein Modell dient dazu, Vereinfachung vorzunehmen.
Und deswegen machen wir das so, dass wir eigentlich die Entwicklung,
nämlich diesen Übergang von Problemraum zu Lösung haben,
an der Vereinfachung machen am Modell.
Also wir erstellen ein Modell des Problemraums und daraus ein Modell
des Lösungsraums. Das ist dann der Entwurf.
Und überführen das in die Realität, in ein Softwaresystem.
Und dabei lassen wir uns helfen von Dingen,
die Erfahrungen durch Erfahrungen angereichert worden sind und durch Methoden.
Den Problemraum verstehen und dann ein Modell, eine Vereinfachung zu finden,
das ist der Job des Requirements Engineering einer Teildisziplin und die Objekte orientierte Analyse.
Wir finden fachliche Objekte. Das spielt alles hier eine Rolle
. Das wird durch die Methode warm,
die wir hier gelegentlich erwähnen, auch schon mal
mit unterstützt
Beim Übergang vom Modellraum, vom Problemrund zum Lösungsraum,
lassen wir uns unterstützen durch Entwurfsregeln, Regeln für guten Entwurf,
Entwurfsmuster, die etwas, die etablierte Lösungen verkörpern.
Wir hatten schon das Beobachtermuster in den letzten Vorlesungen besprochen und eben auch Entwurfsprinzipien.
Das soll heute im Fokus stehen. Dabei, die sollen
dazu dienen, einen guten Entwurf zu erreichen. Ja,
und wenn wir dieses Modell des Lösungsraums haben,
den wir auch Entwurf nennen, dann implementieren wir das,
zum Beispiel mit Programmierregeln,
wieder mit Entwurfsmustern,
die hier auch schon
eine Rolle gespielt haben
Entwickeln daraus wirklich ein wirklich ausführbares Software-System, während das die Vereinfachung ist,
eben der Entwurf, in dem viele Details noch empfehlen,
machen wir hier ein Software-System daraus.
Ja, und was sind da die Dinge,
die das beschreiben, also hier eine Anforderungsbeschreibung,
hier ein fachliches Klassenmodell,
hier entwickeln wir eine Architektur und Komponenten und hier haben wir tatsächlich die Implementierung,
also Quellcode,
Pakete und noch vieles drumherum
Soweit erst mal zum Einordnung, worum es hier geht,
wo wir beim Entwurf drüber reden und wo denn eigentlich
diese Entwurfsprinzipien hingehören, mit von denen wir heute sprechen.
Entwurf, so hatten wir schon mal erwähnt,
ist die Überführung aus dem Problembereichsmodell in eine technische Lösung.
Also wir bauen aus der Aufgabenstellung, die aus der fachlichen,
was im Modell der fachlichen Aufgabe, bauen wir eine Lösung.
Eine kleine Warnung hier, diese bestehende Struktur, die wird auch manchmal mit Entwurf bezeichnet.
Also ich habe, da ist ein Stück Entwurf.
Die Tätigkeit entwerfen müsste es eigentlich heißen, ist leider durch das gleiche Wort gekennzeichnet beschrieben. So,
wir wollen, wenn wir große Systeme entwickeln,
möglichst gleichartig vorgehen, damit wir uns,
damit sich Menschen gegenseitig darüber austauschen können, wie macht man das,
damit wir die Aufgabe auch in jemand anderes Hände geben können,
der es dann in gleicher Weise macht.
Deswegen wollen wir Methoden anwenden, wir wollen strukturiert vorgehen,
damit wir auch große Systeme beherrschen und solche Methoden sind zum Beispiel das,
was wir hier Grundzügen gelegentlich erwähnen, diese Methode,
wann oder Scrum eine Methode iterativ zu arbeiten.
Ja, wir wollen dabei Strukturen gestalten. Gleichzeitig treffen wir
Entscheidungen. Entscheidungen über dieses Umsetzen in eine technische Lösung.
Zum Beispiel, ob wir ein Entwurfsmuster anwenden. Das Beobachtermuster
ist ein Beispiel dafür für eine bestimmte Menge von Problemen.
Ist das eine gute Lösung für andere? Gibt es
andere Entwurfsmuster oder so? Wir müssen die noch irgendwie ein
bisschen anpassen. Oder wir wenden etwas an,
was jemand anders schon gebaut hat, was direkt einsetzbar ist.
Ein Datenbankmanagement-System,
eine Klassenbibliothek,
irgendein Werkzeug
Das kaufen wir oder wir bekommen es für kostenlos,
wenn es Open Source sein sollte.
Und wir gestalten Schnittstellen so, dass wir Altes und Neues,
Existierendes und München nur zu entwickeln, das zusammenpassend, passend machen können.
Und gleichzeitig versuchen wir Entwurfsprinzipien anzuwenden für all die Sachen,
für die das Obere nicht passt, für die wir nichts,
keine Entwurfsmuster finden, für die wir keine fertigen Bausteine entwickeln,
für die wir den Code schreiben.
Das ist das, was wir
hier tun wollen
Wir wohl versuchen, ingenieurmäßig vorzugehen, das heißt Wissen von
anderen, Wissen, von unseren Vorgängern zu nutzen.
Und dass dieses Wissen über erfolgreiches Problem lösen, dann anzuwenden.
Ja, das gibt es, ich hatte gerade den Qualitätsstandard
25.010 erwähnt. Ja, dann gibt es noch Vorgehensweisen,
Entwurfsmethoden, Entwurfslösung, bis hin zu ganz konkreten Sachen.
Also das sieht in der ersten Punkt, sind die ganz,
ganz abstrakten Dinge, die man kaum als Beitrag zur Lösung erkennen kann.
Ja, bei Vorgehensweisen weiß man, wie es,
gibt es wenigstens die Schritte, bei Entwurfsmethoden
Prinzipien dann ist es schon ein bisschen gegenständlich,
aber es ist auch nicht wirklich anwendbare Lösungen.
Bei Design-Patterns, Entwurfsmustern, das ist wenig das Muster einer Lösung.
Und etwas ein richtiger Baustein, ja, das ist ausführbarer Code.
Das ist also diese Abstraktionsebene, die wir haben,
wenn wir etwas als Hilfsmittel verwenden können.
Und gleichzeitig gibt es eine Einteilung oder für bestimmte Arbeitsgebiete etwas Spezialisiertes.
Für die Implementierung, da arbeiten wir bezüglich, spezialisieren wir
uns auf den Quellcode. Für den Entwurf im Kleinen,
wir haben die beiden Begriffe Entwurf im kleinen Entwurf im Großen,
hier kümmern wir uns um die Gestaltung von Klassen,
von Schnittstellen
Für die fachlichen Blöcke, die wir haben, Pakete,
Komponenten, versuchen wir, Methoden zu verwenden,
die das fachliche auch mit berücksichtigen,
wie eben zum Beispiel Wamm oder das Domaintreffen Design,
was in der Vorlesung von Dr. Grützern mehr verwendet wird.
Ja, und wir versuchen, in dieser Vorlesung gehört auch mit zum Softwaretechnik,
was sich schon ein paar Mal beworben habe, im vierten Fachsemester.
So, ja, oder im Entwurf, im großen Softwarearchitekturen,
das ist etwas, da kann ich sie,
das für das Masterstudium einladen,
da gibt es eine Vorlesung,
Wir beschäftigen uns hier mit diesen Sachen wirklich nur so ganz
am Rande oder ganz oberflächlich, sag ich mal,
indem wir über Pakete sprechen, über Strukturen sprechen.
Soweit Entwurf. Nun die Frage, wann ist der gut?
Diese Frage ist ein bisschen schwierig zu beantworten. Deswegen machen wir
hier sehr viele Worte drum. Deswegen gibt es diese Prinzipien,
das gibt es die Methoden und wir nehmen sehr grundlegende Prinzipien
an und erklären hier diese grundlegenden Prinzipien.
Zunächst erst mal zwei ganz wesentliche lose Kopplungen,
hohe Kuhision
Das sind zwei, wir gehen in die nächsten Folien noch
ein bisschen genauer drauf ein und dann noch, was gehört denn wirklich zusammen?
Wir sprechen bei diesen drei Einstrichen darüber, Module zu bilden,
Dinge zusammenzupassen, die zusammen gehören, das ist das Letzte,
hier und wie kommen wir, wie packen wir die zusammen,
ja so, dass sie miteinander große Zusammenhänge haben,
das ist die hohe Kollision und miteinander nur wenig Abhängigkeiten bilden,
das ist die lose Kopplung.
Ja, und die Prinzipien, die hier stehen,
die werden wir jetzt noch im Einzelnen durchgehen
Lassen Sie uns mit Choreosion anfangen. Das ist
ein Begriff aus der Physik, wie Dinge Zusammenhaltgehör zusammenhalten.
Zum Beispiel bei einer Flüssigkeit sind die Atome, die Moleküle,
haben einen starken Zusammenhalt. Deswegen ist es eine Flüssigkeit.
Beim Gas haben wir viel weniger Zusammenhalt. Und wir nützen
diesen Begriff aus der Physik, um zu sagen,
die Dinge innerhalb eines Moduls sollen eng zusammenhängen.
Und deswegen, und das ist das enge Zusammenhängen,
machen wir über die Menge der Aufgaben, die in einer Softwareeinheit,
das ist jetzt der verallgemeinerte Begriff hier für Modul,
zusammen drin sind
Ja, und wenn etwas wirklich alles nur für eine Aufgabe ist,
ja, dann ist das, hat das eine hohe Koission.
Ja, und wenn wir etwas haben, was mehrere Aufgaben erfüllt,
ja, dann sind irgendwie mehrere Aufgaben darin gemischt.
Das ist eine Verletzung dieses Prinzips,
dieses Ideals oder wenn einer die Erfüllung einer Aufgabe über mehrere Einheiten verteilt,
über mehrere Module fortverhältnis, dann ist es eine andere Art von Verletzung.
Und wir wollen versuchen, möglichst das zu konzentrieren,
dass etwas da drin ist.
Dass etwas zusammengehalten wird
Hohe Kohässion hat das Ziel für uns, dass wir Änderungen wirklich
nur an einem Element durchführen müssen, wenn sich ein Sachverhalt ändert.
Für verschiedene Sachen betrachtet, fangstatten wir mal an,
Kohässion von Klassen. Wir hatten hier bei der vorhergehenden Folie,
ich gehe nochmal zurück, hatten wir immer den Begriff Software-Einheit.
Ich habe das einfach mal vereinfacht mit Modul.
Machen Sie jetzt ein bisschen genauer, wir starten mit Klassen.
Eine Klasse sollte genau eine Sache bedienen. Und hier eine Klasse Film,
ja, wir sehen hier nur die Felder,
Da gibt es hier, das ist der Konstruktor,
wo die Einheit mitgegeben werden und dann gibt es hier die Schnittstelle.
Also hier sehen wir dann so quasi die Felder,
die bei dem Konstruktor landen und hier nochmal die Ghetter,
also der Titel, die Länge, die FSK,
die Freiheit für Freigabe, für Altersklassen oder etwas Überlänge.
Ja, da sind nochmal die gleichen. Also das ist die Schnittstelle,
das ist etwas, was Aussagen über den Film trifft. So,
und jetzt hier haben wir eine Klasse Programm,
wo Ja, in dem Fall mal alles zusammengetan ist,
vielleicht ein bisschen in stark übertriebenes Beispiel,
wo alles zusammen ist, Command-Stack, ja, Bush command,
Popcorn, mein Shutdown, Command, alles Mögliche,
das ist Stadt und Stopp.
Dann ist ein Fehlerreport, ja,
dann gibt es noch globale Daten und Shutdown nochmal,
obwohl es hier Shutdown und Command-Step schon gibt,
das geht irgendwie ein bisschen durcheinander.
Und sicherlich gab es mal eine Idee,
warum man das alles zusammen zu einer Klasse packt,
aber es ist nicht wirklich,
also man hätte wenigstens das mit dem Fehlerreport hier rausziehen müssen.
Hat also hier
eine geringe Kurision
Wir können diesen Begriff Koission auch anwenden auf Methoden.
Und da auch eine Methode sollte genau für eine Aufgabe zuständig sein. Ja,
also hier haben wir zum Beispiel eine im Trikonometrische Funktion oder
gar eine Sammlung von trikonometrischen Funktionen zusammengefasst, in einer Monster-Methode.
Ja, all diese Winkelfunktionen berechnen kann. Und sie bekommt das
dann als Funktionsparameter übergeben. Klar kann man bei Funktionaler Programmierung,
kann man da sowas machen,
aber wenn sie an einem der Sachen was ändern,
müssen sie
dieses Ding anfassen
Ja, und wenn das separat wäre,
würde man bei einer Änderung nur eins anfassen müssen.
Ja, mit entsprechend weniger Code. Ich glaube,
das war es schon, ach genau,
und jetzt hier das Beispiel für Methoden mit hoher Kollision,
wo wir dann die Winkelfunktion einzeln haben.
Und das hat jede für sich, hat erfüllt genau eine Aufgabe.
Und auch bevor wir zur Kopplung gehen, springe ich mal
zurück zur Folie 3, wo wir die Fragen haben.
Da gibt es eine Frage, den Begriff Kollision nennen Sie Indikatoren für hohe Kollision im Code.
Und das war zum Beispiel hier, dass wir nichts haben,
was mehrere noch in Umschalter hat, so wie hier,
dass man die funktionalen Parameter zur Umschaltung hat, oder dass wir hier Sachen haben,
die in irgendeiner Form verschiedene Attribute, verschiedene Felder benutzen.
Das wäre auch denkbar, dass die Felder dafür verschieden sind,
wie diesen Report oder globale Daten oder das Kommando,
dass die verschiedene Sachen zu tun haben,
die hier geht es wirklich immer nur um den Film und seine Parameter.
Soweit zu der Kuhision, ich gehe weiter und das nächste Thema ist Kopplung,
auch nochmal gleich zurück zur Folie 3 mit den Fragen.
Hier haben wir auch eine Frage zur Kopplung,
erklären Sie den Begriff Kopplung, warum ist lose Kopplung erstrebenswert.
Ja, Kopplung beschreibt den Grad der Zusammengehörigkeit zwischen diesen Softwareeinheiten,
also zwischen Klassen, Zwischenmethoden, zwischen Modulen.
Ja, und das sind Abhängigkeiten. Abhängigkeiten ist ein Begriff,
der erstmal auch vielleicht ein bisschen schwer zu greifen ist.
Wir reduzieren Abhängigkeiten jetzt für Objektorientierung auf Benutztbeziehungen und Vererbungsbeziehungen.
Eigentlich sind Abhängigkeiten durchaus, kann das durchaus noch mehr sein.
Wir wollen versuchen, diese Abhängigkeiten so gering wie möglich zu gestalten,
damit eine Änderung, die wir in einem einen Teil machen,
nicht auch zu Änderungen im anderen Teil führt.
So, und diese Abhängigkeiten, die versuchen wir,
das ist eben die Kopplung und wir versuchen lose Kopplungen anzustreben,
damit sich Änderungen nicht auswirken. Nicht nur dieses Änderungen,
das ist der zweite Punkt, den habe ich schon genannt,
ja, Änderungen sind einfacher durchzuführen,
weil eben die eine nicht so stark vom anderen abhängt,
es ist auch besser zu verstehen,
weil um die Aufgabe von dem einen zu verstehen,
muss ich nicht das Gesamtsystem oder noch viele andere zu verstehen,
sondern die Sachen sind voneinander unabhängig.
Ja, also zu Änderungen für Wartung gehört beides,
nämlich das Verstehen und das Durchführen und beides ist einfacher.
Diese Kopplung, von der wir hier sprechen,
dass wir sie lose haben wollen, dass wir sie nicht festhaben wollen,
also gibt es auf x implizite und explizite Weise.
Implizit heißt irgendwie, sie ist nicht so deutlich,
explizit sie ist klar zu sehen und formal nachweisbar.
Zum Beispiel ein richtiger Zugriff über eine öffentliche Exemplarvariable.
Es ist im Quellcode zu sehen, wir haben dort wirklich
einen Zugriff auf eine Variable. Implizite Kopplung ist unangenehmer,
ja, indem wir, weil wir sie nicht wirklich sehen können.
Wir merken sie erst, oh, da gibt es noch
was, was plötzlich nicht mehr funktioniert. Ja,
weil zum Beispiel ein Entwickler weiß,
wie das intern funktioniert und er setzt das um bei irgendwie Sortierprinzipien,
weil er weiß, das ist irgendwie immer in dieser Reihenfolge,
das mache ich dort auch.
Und dann, wenn wir die Reihenfolge aus irgendwelchen Performance-Gründen ändern,
plötzlich funktioniert was nicht mehr
Irgendwie schwerer zu erkennen und deswegen auch schwerer zu beheben,
auch schwerer zu prüfen. Explizite Sache, da ist das offensichtlich,
das steht dort, das können wir im Quellcode nachlesen.
Also lose Kopplungen erstrebenswert, das war ja diese Frage von der Wiederholungsfrage,
weil besser verständlich und leichter durchzuführen. Um die implizite Kopplung mal zu erklären,
hier noch ein Beispiel, wir haben ein Klient und einen fachlichen Container,
einen fachlichen Behälter und da ist die Schnittstelle unter anderem,
dass der fachliche Behälter mehrere Inhalte hat,
und mehrere Teile hat und die Implementierung,
der liefert die alle nacheinander und die Implementierung sagt,
okay, das kommt in alphabetischer Reihenfolge.
Wenn der Implementierer des Klienten diese Implementierung hier kennt und weiß,
die alphabetische Lodierung kommt dann, dann sagt er, okay,
gib mir das Erste, gib mir das Nächste und so weiter und ich weiß, sie sind sortiert.
So, wenn ein bisschen später jemand hier was dran ändert,
aus irgendwelchen zum Beispiel Performance-Gründen oder Speicherplatzverwaltungsgründen oder weil er plötzlich eine andere Sortierung möchte,
der macht außer diese Schnittstelle, nämlich,
dass er die Elemente nacheinander liefert, aber das,
was auch noch intern passiert, da kümmert er sich nicht tun,
weil er es einfach gar nicht wusste,
das war nicht seine Aufgabe und dann funktioniert auf einmal dieses Teil nicht mehr,
weil er sich darauf verlässt.
Ja, das ist ein Beispiel dafür, für diese implizite Kopplung. So,
soweit zu diesem Kopplungsfragen und da hat jemand ein Gesetz formuliert,
im Love Dimita,
das hat also nichts mit der biologisch-dynamischen Nahrung zu tun,
sondern das ist das Gesetz, wo es um lose Kopplungen geht
Und man sollte sich mit den Aufrufen beschränken.
Die offizielle Form ist die hier in dem Kasten.
Eine Methode eines Objekts sollte nur Methoden von dem Objekt selbst aufrufen,
von Parametern der Methode oder von Objekten,
die die Methode Erfolg erzeugt und von Exemplarvariablen des Objekts,
von nichts anderem.
Also nicht etwa, zum Beispiel von anderen Objekten,
die hier Parameter sind,
nochmal Methoden,
sondern nur von selbst
Das ist das Slow of Demeter. Man könnte auch so sagen,
okay, nur den engsten Kreis,
so ein bisschen wie wenn jemanden ansteckt, der Krankheit hat.
Dass sich das nicht verbreitet. Beispiel für eine Verletzung
ist jetzt hier so eine lange Aufrufkette,
die ja durchaus möglich ist, dass wir in Objektorientierung das machen.
Also wir holen uns von dem Student einen Rekord und da
holen wir uns einen Eintrag mit einem bestimmten Bezeichnung und da fügen wir noch was hinzu.
Dass es wäre durchaus zulässig und was wir dabei machen, ist ja, dass wir eine hohe Kopplung zwischen verschiedenen Elementen darstellen. Ja,
also zunächst erstmal, wir rufen Klientes, der,
der uns aufruft, wir rufen den Studenten auf,
und der hat drinnen einen Rekord als Vorweis,
und den Rekord lassen wir uns geben, das heißt,
dieser Ausdruck liefert einen Rekord, und damit hat der Zugriff auf den Rekord,
und in dem Rekord ist ein Exime-Entry drin,
das ist dieser Pfeil hier, da steckt da drin,
und mit diesem ersten drei Punkten hier teilen kommt,
greifen wir darauf zu.
Und diese Methoden sind dadurch sehr eng aneinander gekoppelt,
wenn sich hier drin was ändert,
Ich rufe das ja gar nicht direkt auf,
sondern nur über diese Kette.
Dann kann es sein, ich muss das,
das oder das oder alle zusammen ändern.
Und das hat höheren Aufwand zur Folge, häufigere Änderungen.
Jedenfalls muss ich es jedes Mal prüfen. So,
und wenn wir jetzt, wie können wir das verbessern?
Wie können wir das auflösen? Wir können zum Beispiel
eine Methode machen, die ein Resultat liefert.
Ja, also irgendwie hat jemand ein bewertetes Resultat und das
können wir
direkt zugreifen
Ja, und die Methode selber greift wieder auf etwas
zu und da wiederum eine Methode greift wieder etwas zu.
Und da ist das lokal in der Methode nur gekapselt. Ja,
so, also wir fragen nicht, ein anderes Beispiel,
ja, wir fragen nicht in Satelliten, sag mir ja,
was deine Antriebsdüsen gerade machen und nimm die hintere Rechte und mach ein kleines bisschen mehr Gas,
sondern wir sagen lieber Satellit, halte diese aufrechte Position.
Und ganz allgemein sollten wir immer fragen, wer ist denn zuständig?
Diese Frage der Zuständigkeit, die werden wir heute
noch häufiger hören
So, dabei merkt man,
wenn man das ein bisschen diskutiert,
ich greife dieser Diskussion mal vor, aber sie können,
ich bin ziemlich sicher, dass sie darauf kommen werden,
wenn sie das mit Kollegen mal diskutieren bei ihrem nächsten,
bei ihrem nächsten Entwurf.
Und da werden sie merken, oh, das mit
den Ghettern und Settern ist doch manchmal nicht so einfach.
Ja, weil wir doch direkt darauf zugreifen.
Und damit ist doch das, was eigentlich private sein sollte,
geben wir nach außen oder beeinflussen das direkt.
Das erzeugt auch Ghetter und Setter,
erzeugen sehr direkte,
sehr enge Kopplung
Soweit zu dem ersten Abschnitt. Wir haben die Frage 3
auch schon mit beantwortet. Das war die Frage,
das war das Gesetz von Lore of Demeter.
Ja, Verbesserungen vorzuschlagen, das war jetzt Folie 15 bis 18.
Soweit im ersten Abschnitt. Und wir machen gleich weiter mit
dem Nächsten