Hi. Heute geht es um Entwurfsprinzipien. Dazu wird es
auch wieder zwei Videos geben. Eine Gruppe von den Wurst-Prinzipien sind diejenigen,
deren Anfangsbuchstaben sich zu dem Wort Solid kombinieren lassen.
Single Responsibility Principle, Open Close Principle, Lizcoff Subsubsubsubsubsitution Principle,
Interface, Cecregation Principle und Dependency Inversion Principle.
Was genau sich dahinter verbirgt, das hat ihr
in dem Teil von Professor Riebisch schon genauer gesehen.
Allerdings Open Close Principle klingt so ein ganz klein bisschen weird.
Deswegen werden wir uns das an ein Code Beispiel
im zweiten Video ansehen
Und insgesamt noch das Ding kennt ihr bis zur Klausur auswendig.
Ich kann mich an einen Klausurtermin erinnern, wo das mal nicht gefragt wurde.
Ansonsten war das immer dran. Bisher, ich weiß natürlich nicht,
ob die das weiter so machen. Bisher war es immer so,
dass sie die Anfangsbuchstaben hingeschrieben haben und ihr musstet das so ergänzen,
wenn die Leute es nicht gewusst haben,
haben wir für S öfter mal lustige Antworten mit sexy gekriegt.
Für uns lustig, für euch verschenkte Punkte,
also nochmal das Ding solltet ihr bis zur Klausur auswendig kennen.
Weiteres Entwurfsprinzip ist das Lore of Dame Ether. Sehen wir
uns das mal an. Eine Methode M eines Objekts O
sollte ausschließlich Methoden von folgenden Objekten aufrufen. Von O selbst,
von Parametern von M, also von dieser Methode, von Objekten,
die diese Methode erzeugt und von Exemplarvariablen von O. Wow.
Für mich klingt das eher so mittelverständlich und deswegen
gucken wir uns das Ganze jetzt auch mal an einem Codebeispiel
ein bisschen näher an
Dazu habe ich hier ein paar Klassen vorbereitet.
Das lehnt sich so ein bisschen an einer Aufgabe an,
die mit der Mediathek zu tun hatte, aus den Jahren davor.
Da hatten wir einen Übungszettel mehr, der ist jetzt weggefallen
wegen der gegebenen Situation. Und dann sollte man die Möglichkeit
schaffen, dass Leute auch ein Medium vormerken können.
Es sollten bis zu drei Leute sein, die wurden dann
auf so einer Formerkarte gespeichert und das Ganze wurde vom Verleihservice-Impel mitverwaltet.
Gucken wir uns die Klassen einfach mal an.
Wir haben hier Adresse, das besteht aus einer Straße,
eine Hausnummer und einer Mail
Wir haben einen Kunden, einen Vornamen, Nachnamen, eine Kundennummer und eben so eine Adresse. Medium ist eine leere Klasse,
die habe ich einfach nur deswegen gebaut,
weil ich im Verleihservice Imple,
was vom Typ Medium gebraucht habe und damit da nicht gemeckert wird,
habe ich halt hier diese leere Klasse gebaut,
vor mehr Karte, darauf werden eben diese Vormerker gespeichert,
das passiert hier eine List mit Element Typ Kunde und diese List können wir uns auch zurückgeben lassen,
hier über den Ghetter und dann haben wir hier den Verleihservice Imple,
der hat eine Map mit Key Medium und Value vor mehr Karte.
Das heißt, so jedem Medium wird eine Vormerkarte in dieser Map abgelegt.
Das Ganze ist eine Hashmap. Und wir haben hier
diese Methode, Get Mail für ersten Vormerker für Medium.
Und hier haben wir eine ziemlich lange Aufrufkette. Das heißt also,
wir lassen uns hier aus dem Hashmap,
aus der Hashmap vor mehr Karten, die vor mehr Karte,
die zum bestimmten Medium gehört, geben,
rufen,
holen uns von dieser Vormerkkarte die Liste der Vormerker
Holen uns davon das nullte Element. Das ist dann ein Kunde,
holen uns von dem Kunden die Adresse, also was von der Klasse Adresse,
und holen uns aus der Adresse die Mail.
Das ist eine ziemlich lange Aufrufkette und das Lore of Demeter
dient eben dazu, solange Aufrufketten zu vermeiden.
Warum sollte man die vermeiden? Die Klasse Verleihservice-Impel Hat hier
ganz offensichtlich Kenntnis darüber, wie die Vormerke auf der Vormerkarte gespeichert werden.
Wenn wir uns das hier nochmal ansehen, das ist eine List.
Und wenn wir an das nullte Element einer Liste kommen wollen,
also an das Element mit In-Exposition null,
dann rufen wir eben auf der Liste.get0 auf.
Wenn jetzt aber irgendjemand auf die Idee kommt zu sagen,
es soll ja sowieso nur bis zu drei Vormerker sein,
also packen wir das Ganze nicht in eine Liste,
sondern in Ray.
Wenn wir da in das nulltelement wollen,
müssten wir nicht.get0 nehmen,
sondern eckige Klammer null
Irgendjemand kommt auf die Idee, dass dahingehend zu ändern,
dass wir drei Exemplar variabel und vom Typ Kunde haben,
vor Merkel 1, von Merkel 2,
von Merkel 3. Egal, was hier geändert wird,
wir müssen hier in Verleihservice Impel auch was ändern.
Das Gleiche gilt hier für den Kunden.
Wir haben hier auch wieder Kenntnis darüber,
wie der Kunde seine Mailadresse verwaltet,
weil wenn wir uns hier Kunde ansehen,
da haben wir hier ja was vom Typ Adresse,
ein Exemplar variable und über diese Adresse können wir
uns die Mail rausgeben lassen
Wenn jetzt aber irgendjemand auf die Idee kommt zu sagen,
warum brauchen wir eine eigene Klasse,
Adresse für die drei Exemplarvariablen, die hier drin sind.
Und packt das alles dann anstatt Adresse hier mit rein.
Dann haben wir auch wieder hier ein Problem,
dass wir hier auch wieder was ändern müssen.
Das heißt also, wenn irgendwo auf dem Weg dieser Aufrufkette
irgendeine Entwurfsentscheidung geändert wird, müssen wir an mehreren Stellen was ändern.
Und das ist einfach nicht gut. Also bauen wir es
mal anders. Ich kommentiere das hier einfach mal aus,
damit wir noch weiterhin sehen, was da so stand.
Und dann schreiben wir Return
Vormerkkarten brauchen wir natürlich immer noch, und zwar die,
die zu einem bestimmten Medium gehört.
Und dann könnten wir dieser Vormerkkarte ja einfach mal sagen,
gib uns da die Mail-Adresse für deinen ersten Vormerkern.
Das machen wir mal, Punkt. Get, Mail für
ersten Vormerker. Klammer auf, Klammer zu, Semikolon.
Die gibt es natürlich noch nicht, aber wir können sie
uns machen lassen. Und dann würden wir hier im Prinzip
uns aus der Liste der Vormerker das nullte Element geben lassen.
Das ist dann ein Kunde, und auf dem würden wir aufrufen,
Get Mail. Gibt es natürlich auch noch nicht.
Können wir uns auch erzeugen lassen. Jetzt haben wir dann
hier. Und hier würden wir dann einfach unsere Exemplare variabler
Adresse nehmen.
Und auf der Get Mail aufrufen
Wenn wir uns jetzt für Live-Service Imple nochmal ansehen,
dann haben wir hier eine deutlich kürzere Aufrufkette.
Die sieht natürlich irgendwie nicht kürzer aus, was allerdings nur daran liegt,
dass wir hier einen relativ langen Namen haben,
aber die Aufrufkette an sich ist tatsächlich kürzer,
weil bis auf die Tatsache,
dass wir uns hier mit dem Get eine Vormerkkarte besorgen müssen,
machen wir nur einen weiteren Aufruf.
Gucken wir uns doch mal an, was das hier mit unserem Entwurfsprinzip bedeutet,
die Methode soll nur Objekte von Exemplarvariablen von O-Aufrufen.
Wir haben hier eine Exemplarva-Jable, wo einer der Elementtypen vor mehr Karte ist,
die steht dann im Prinzip hier und auf der rufen wir eine Methode auf.
Das passt. Dann gucken wir uns nochmal vor mehr Karten
an. Warum hier Get Mail rot ist,
das wissen nur die Götter der Sonnenfinsternis,
weil wir sehen hier oben mit den Klassen stimmt eigentlich alles.
Das hier ist Clips Magic. Aber gucken wir uns das bezüglich
Law of Dimator an. Wir haben hier eine Exemplarva-Jable mit
Element Typ Kunde und rufen auf diesen Kunden dessen Methode Get Mail off.
Das heißt, wir bewegen uns wieder hier, Exemplar raiable von O.
Sehen wir uns Kunde an. Wir haben eine Exemplarvariable vom
Typ Adresse. Und auf dieser Exemplar war ja,
bin ich mal das nochmal hin, damit man es sieht,
auf dieser Exemplarvariable rufen wir die Methodik Get Mail auf,
passt auch. Das heißt also,
Law of Demeter ist erfüllt und wenn wir uns hier das nochmal angucken können,
es kann uns vollkommen egal sein,
auf welche Art und Weise die Vormehrkarte hier zum Beispiel die Vormerker speichert,
weil wir über diese Methode Get Mail für ersten Vormerker Egal wie die Vormerkel hier drin abgelegt sind,
einfach die Mail holen können.
Und da wir hier einen Kunden haben,
kann es uns auch egal sein,
wie der Kunde seine Mail-Adresse hier verwaltet,
ob das in Adresse drin steckt oder eben nicht.
Weil wir haben hier einfach die Methode Get Mail und
der Kunde besorgt uns dann die Mail-Adresse.
Insofern erfüllen wir das Law of Demeter und wir haben auch das vermieden,
was wir mit im Law of Demeter tatsächlich auch vermeiden wollen,
dass wenn irgendwas geändert wird, wir an mehreren Stellen was ändern müssen.
Jetzt haben wir nur ein anderes Problem
Wir wollen ja auch einen Entwurf nach Zuständigkeiten machen.
Und garantiert ist die Formel-Karte nicht dafür zuständig,
uns von irgendjemandem eine Mail-Adresse zu besorgen. Das heißt also,
wir verstoßen hier schon gegen den Entwurf nach Zuständigkeiten.
Und deswegen bauen wir uns einfach nochmal eine andere Variante davon.
Ich mache das hier einfach mal. Alles zu.
Das hier ist das Gleiche, wie unser Anfangszustand vorher.
Ich wollte nur an dem, was wir eben gemacht haben,
nichts verändern, falls wir es uns nochmal ansehen wollen.
Wir haben hier also wieder Verleihservice Impel mit dieser langen Aufrufkette,
die ich auch mal wieder auskommentiere
Jetzt könnten wir uns ja mal eine lokale Variable vom Typ Kunde bauen,
die, das waren natürlich Großscheiben,
die nennen wir Kunde und die bekommen wir,
indem wir uns die Vormerkkarten für ein bestimmtes Medium geben lassen
oder die Formelrkarte für ein bestimmtes Medium geben lassen.
Und auf dieser Vormerkkarte die Methode Get,
ersten Vormerker
Ich glaube, aufgenommen zu seinem Cola. Aufrufen. Die
Methode gibt es natürlich wieder nicht. Wir lassen sie uns bauen.
In der Vormerkkarte, hier haben wir Get ersten Vormerker.
Nehmen wir das hier mal raus. Und auf der Liste
der Vormerker oder aus der Liste der Vormerker,
lassen wir uns das nullte Element geben.
Und das ist dann der erste Vormerker. Dann haben wir
hier unseren Kunden Und dann können wir ja einfach sagen,
können wir gleich einen Return davor schreiben.
Auf diesem Kunden rufen wir dann eine Methode, Ed Mail auf.
Die ist natürlich auch noch mal wieder nicht gibt. Steuerung 1,
Create Method, dann sind wir im Kunden,
dann machen wir das, was wir schon mal gemacht haben,
indem unser Exemplar variable Adresse und rufen darauf Get Mail auf
Okay, was haben wir dadurch erreicht? Hier muss uns nicht interessieren,
wie auf so einer Vormerkkarte, die Vormerker gespeichert sind,
weil wir der einfach direkt sagen, gib uns den ersten Vormerker.
Ja. Die gibt uns einfach den ersten Vormerker raus.
Wie der Kunde seine Mail speichert, kann uns auch vollkommen egal sein,
weil wir haben hier im Kunden eine Methode Get Mail
Wenn das hier geändert wird,
dass es nicht mehr in so einer Adresse drinsteht,
sondern auch ein Exemplarvariable ist,
dann würde er hier einfach direkt die Exemplarvariable zurückgeben.
Alles ist gut. Fachlich ist so eine Vormerkkarte ganz sicher
dafür da, uns einen Kunden zurückzuliefern.
Ein Vormerker zurückzuliefern. Ein Kunde ist auch dafür da und
seine Mailadresse zu liefern.
Insofern ist fachlich auch alles in Ordnung. Jetzt gucken wir
uns mal Law
of Demeter an
Und schon haben wir ein Problem,
weil wir haben uns hier eine lokale Variable erzeugt.
Das ist also nicht eine Exemplarvariable von, oh,
wir könnten sie uns hier natürlich irgendwie künstlich reinbauen,
aber eigentlich hätten wir sie ja gar nicht haben wollen.
Das hätte dann einen anderen bitteren Beigeschmack gehabt oder Geschmäckle,
wie unsere badischen Freunde sagen. Das heißt,
dieses Law of Damater ist auf alle Fälle nicht erfüllt.
Welcome to the real world. Diese Entwurfsprinzipien,
die lassen sich halt nicht immer ganz genau buchstabengetreu ein
Halten, beziehungsweise widersprechen sich ganz, also widersprechen sich nicht,
aber manchmal führt es zu Bedingungen, dass man eben nicht mehrere Entwurfsprinzipien,
die man gerne hätte, einhalten kann.
Und dann muss man eben abwägen, welches einem wichtiger ist.
Ich fände, das ist meine ganz private Meinung,
die zweite Variante, deswegen ein bisschen besser,
weil wir den Zweck des Laufdemeters erfüllen,
wir können ändern,
wo wir wollen und wir müssen es nur an
der Stelle ändern
Und wir haben einen Entwurf nach Zuständigkeiten, was ich eigentlich auch ziemlich schön finde.
Aber wie gesagt, da muss man dann abwägen,
da mögen andere Leute auch andere Meinungen zu haben.
Okay, das war es jetzt von mir für den
ersten Teil und den zweiten Teil sehen wir uns,
dass etwas komisch klingende Open Close Principal ein bisschen näher
an.
Bis dann