Latest / Coding Buddies | Tech & Dev-Mindset / Warum SOLID deinen Code rettet (und dich auch)

Transcript

Warum SOLID deinen Code rettet (und dich auch) · Coding Buddies | Tech & Dev-Mindset

0:00
Zu Kellner mäßig und Kellner, also Roboter, Kellner, so
0:06
Roboter, Kellner klingt wieso ein Film Ey Coding Buddies Dein
0:10
Podcast rund um Softwareentwicklung und
0:12
aktueller Tech News. Herzlich Willkommen.
0:27
Halli Hallo und herzlich Willkommen zur neuen Folge des
0:29
Coding Buddies Podcast. Schön, dass du wieder
0:31
eingeschaltet hast, deine Gastgeber.
0:33
Und wie soll es anders sein? Meine Wenigkeit, der Tino und
0:36
der fantastische Fabi, der mich hier angrinst, schon der hat
0:39
Bock. Ich seh es schon förmlich.
0:40
Ich begrüße dich, fabi, was geht ab, was geht ab, Tino, wie
0:44
geht's hier steht's alles gut, alles fit, alles.
0:47
Super. Ich hab für die Anmoderation ja.
0:49
War richtig energiegeladen. Ich bin so reingerannt weißt du
0:52
immer so? Jaja, geklappt, so yeah, was
0:54
geht, was geht, was geht so ganz alleine durch den Raum gerannt,
0:57
das. Geht in meinem Kopf vor.
1:01
Nein, also ich seh wir haben Bock ich hab.
1:04
Doch ein geiles Thema, aber 1 vorweg noch ganz kurz Werbung in
1:08
eigener Sache und zwar, liebe Zuhörerin, lieber Zuhörer, falls
1:12
du noch auf der Suche nach einer richtig geilen id i bist,
1:15
empfehlen wir dir wärmstens die Jet Brains ID is.
1:18
Die haben für sämtliche Sprachenlösungen, die Mega geil
1:20
sind, die wir auch selbst verwenden kannst dich gerne
1:23
davon überzeugen, in einem von unseren Livestreams auf Twitch,
1:26
da verwenden wir sie auch immer. Und warum merke ich das an?
1:29
Weil du mit dem Code Coding Buddies 25% auf die
1:34
Jahreslizenzen sparen kannst und das sogar Stacked mit deinen
1:37
vielleicht vorhandenen Ersparnissen, die du eh schon
1:40
hast, weil nach einem Jahr zum Beispiel kriegt man eh schon
1:43
Rabatte. Ganz genau.
1:45
Und der Code ist auf jeden Fall noch mal den Shownotes verlinkt,
1:47
findet ihr aber auch auf unserer Website.
1:50
Also einfach mal reingucken und Spaß haben mit einer.
1:54
Jetbank schaut euch mal an. Genau.
1:56
Werbung Ende jetzt kommen wir zum eigentlichen Thema Fabi.
2:01
Es ist ne Weile her, schon da haben wir uns um so Coding
2:06
Principles gekümmert, was heißt gekümmert sie besprochen zum
2:10
Beispiel das jagni Prinzip. Kiss zum Beispiel.
2:13
Kiss hatten wir gemacht, genau und da würde ich heute gerne
2:17
noch mal ansetzen und ein sehr bekanntes und verbreitetes
2:21
Prinzip. Noch mal besprechen mit dir
2:24
heute, aber es geht n bisschen mehr in die Architekturrichtung
2:28
bei dem Thema. Deswegen an der Stelle ne
2:32
Triggerwarnung für alle, die Objektorientierung nicht so geil
2:35
finden. Heute wird es n bisschen
2:38
objektorientiert hier und wir versuchen es natürlich mit
2:40
Analogien und einfach zu erklären, werden aber nicht drum
2:44
rum kommen das auch so n bisschen an vereinfachten
2:47
Codebeispielen zu erklären. Und zwar fabi.
2:50
Was ist das Thema, Hau mal raus. Das Thema Es geht um Solid, das
2:55
sind ja quasi mehrere Prinzipien in der Softwareentwicklung, die
3:01
kommen auch von Robert C. Martin, also Onkel Bob, Wir
3:06
hatten ja auch mal über. Onkel Bob?
3:09
Ja, geil. Wir hatten ja auch mal eine
3:11
cleancode Reihe gehabt hier im Podcast und da kann man
3:17
vielleicht ne also. Der ist ja auch der Verfechter
3:20
Gründer von Clean Code. Genau deswegen noch mal sei, sei
3:25
das noch mal angemerkt, wenn dich das interessiert, dir liebe
3:27
zuhören, hör auch gern mal in die Reihe in die Clean Code
3:31
Reihe von uns rein, ganz genau und solid sind ja wie ich meinte
3:37
mehrere Prinzipien und es sind quasi jeder Buchstabe steht für
3:42
ein Prinzip. Ja.
3:45
Und da würd ich sagen, lass uns doch einfach mal durchgehen
3:48
durch die einzelnen Prinzipien. Das sind ja im Endeffekt sind
3:51
das ja 5 ne, also einmal für das SOLID und dann gehen wir einfach
3:56
mal durch, nehmen uns jeden Buchstaben raus, geben
3:59
vielleicht ne kleine Analogie dazu, dass man sich es erstmal
4:02
schön entspannt vorstellen kann, was das ist, beschreiben, worum
4:05
es da geht, gehen halt auch mal n bisschen auf so n paar
4:08
Codebeispiele, vereinfacht wie du meintest ein ja und ja, ja
4:13
das ist der Fahrplan. Ja, würde ich sagen, solide
4:17
vorgestellt, Fabi, sorry, der muss so sein.
4:21
Ich würde aber noch mal noch so ganz kurz um das Thema so ein
4:24
bisschen smooth einzutauchen, noch sagen, warum ist es denn
4:29
überhaupt wichtig, eine gute Softwarearchitektur zu haben,
4:32
also weil das Prinzip oder die 5 wie du gesagt hast, zielen ja
4:35
ganz klar darauf ab, genau das zu verbessern, also wirklich
4:39
eine gute Architektur umzusetzen um gewisse Vorteile daraus zu
4:43
ziehen. Und fällt dir zum Beispiel n
4:47
Beispiel, fällt dir zum Beispiel ein Beispiel ein.
4:50
Meine Güte, wo du gemerkt hast, ey, hätte ich es mal vielleicht
4:54
nach so einem Prinzipien umgesetzt, wo du gemerkt hast,
4:57
so an diesem Projekt ist die Architektur wirklich echt nicht
5:00
vorteilhaft, ich stoß hier gerade so an Grenzen, was wären
5:03
so typische Grenzen, die man da, auf die man stoßen könnte, das
5:07
wäre vielleicht mal so das Ganze noch n bisschen motivieren.
5:11
Gute Frage, da muss ich natürlich erstmal mein Gehirn
5:14
rumkramen also ich, ich glaube, dass man auf jeden Fall, gerade
5:19
wenn man irgendwann anfängt und immer weiter sag ich jetzt mal
5:23
ne, also unser Weg ja zum Beispiel Studium, da hat man ja
5:28
auch angefangen Programme zu machen, Programme zu
5:31
implementieren, die jetzt aber noch nicht so ne Architektur
5:35
benötigt haben. Sag ich jetzt mal, weil das
5:38
waren halt kleine Programme. Je größer dann ne Anwendung
5:42
Programm ne Anwendung wird, desto wichtiger ist es natürlich
5:44
sich um eben die die die Architektur zu kümmern, dass man
5:50
halt auch wirklich die Möglichkeit hat zu sagen, ich
5:53
verändere jetzt was an meiner Software, ohne dass ich aber
5:57
gleich die ganze Software umkrempeln muss und das ist ja
6:03
im Endeffekt, darauf zielen ja eigentlich diese Prinzipien ab.
6:07
Und ich überlege gerade, wo ich so was mal hatte.
6:10
Also ich hatte auf jeden Fall diese, diese diese Situation
6:13
schon mal, dass du wirklich gesagt hast, ey, ich habe jetzt
6:16
zum Beispiel eine Klasse und möchte jetzt irgendwie eine
6:18
Klasse ändern, oder ich will da noch was hinzupacken, also
6:22
angenommen, du hast vielleicht irgendwann mal eine Klasse
6:24
gehabt, die hieß zum Beispiel weiß nicht Payment Service oder
6:30
so was auch immer und und darüber wird bezahlt, so und
6:33
dann hast du einen. Payment, was du irgendwie also
6:36
eine Möglichkeit zu bezahlen und das reicht erstmal.
6:39
Und dann fügst du irgendwann noch mal was hinzu und dann
6:42
denkst du so ja OK das das passt auch erstmal so und dann sagst
6:45
du aber hast du irgendwie so n IF Else und sagst ja gut wenn es
6:48
wenn zum Beispiel der Kunde Variante 1 auswählt, dann bezahl
6:52
halt mit Variante 1 Else ne also ansonsten bezahl mit Variante 2
6:56
so und dann kommt man irgendwann relativ schnell in so n struggle
6:59
und sagt Na OK warte mal aber jetzt muss ich vielleicht
7:02
irgendwie. Noch 1 hinzufügen und dann bist
7:06
du bei einem IF LS if LS, dann sieht es irgendwie eklig aus.
7:10
Dann hast du vielleicht noch andere Verhaltensweisen, wie
7:13
sich so n bezahlservice dann im Endeffekt wirklich verhält und
7:17
dann codest du alles in ein so ne Klasse rein und denkst dir
7:19
irgendwann. Oh Gott, wenn ich das jetzt
7:21
anfasse, warte mal. Ich hab jetzt hier ne private
7:23
Funktion, die aber überall aufgerufen wird und wenn ich die
7:26
verändere, dann verändere ich ja vielleicht irgendwas anderes in
7:29
in einer Bezahlmethode, was ich gar nicht.
7:30
Möchte aber nicht genau. Also nur mal als Beispiel jetzt
7:33
ne, also es war jetzt nicht explizit das was ich erlebt
7:35
hatte, aber sowas ähnliches ne, dass du erst mal anfängst sagst
7:38
OK ich hab jetzt das so und so und.
7:42
Also ich hab jetzt eine bestimmte Sache, die muss dann
7:44
erweitert werden und dann aufgrund von muss man dann sagen
7:48
früher aufgrund fehlendem Wissens hat man erstmal drauf
7:51
los programmiert bis man dann irgendwann gemerkt hat oder bis
7:55
ich dann irgendwann gemerkt hab boah ey, das skaliert ja
7:57
überhaupt nicht ne. Und das ist halt auch schon
8:00
Gutes. Stichwort Skalierbarkeit und
8:03
Wartbarkeit. Ich mein, die Worte fallen sehr
8:05
oft bei uns im Podcast, weil sie halt in der Softwareentwicklung
8:07
so unfassbar wichtig sind. Und das sind halt so die
8:10
Erfahrung, die man glaub ich gerade als Einsteiger macht und
8:13
vielleicht auch in den ersten Projekten, wie du so schön
8:16
sagtest. So kleine Programme oder
8:19
vielleicht so kleine Prototypen und Du entwickelst sie immer
8:21
weiter, dann kommt halt noch mehr Anforderungen dazu, mehr
8:24
Funktionalität und du kommst irgendwann an den Punkt, wo du
8:27
dir denkst, oh mein Gott, jetzt ist das wirklich so.
8:29
N Spaghetti Spaghetti Code geworden, es ist so
8:31
verschachtelt und wenn ich jetzt an der Stelle die Funktion
8:34
änder. Soll sich aber nur auf A und B
8:37
auswirken, aber nicht auf C und D.
8:39
Aber so wie das hier gerade umgesetzt ist, zieht sich das
8:42
durch die ganze Software und ich hab eigentlich schon gar keinen
8:44
Überblick mehr was passiert, wenn ich jetzt diese Funktion
8:47
anfasse und das sind so Klassiker und sowas haben wir
8:51
auf jeden Fall selbst erlebt. Also wenn du dann noch keine
8:54
Tochter hast, wenn du dann noch keine Test eieieiei und die
8:58
hatte ich damals auf jeden Fall nicht.
9:00
Ich ja auch nicht. Und da denkt man sich so, ha,
9:04
wie hätte man das denn besser machen können?
9:05
Also wie hätte ich von Anfang an dafür sorgen können, nicht in
9:09
diese Falle zu laufen oder quasi mit dem Rücken zur Wand zu
9:13
stehen und sich zu denken, ich glaub ich muss von vorne
9:15
anfangen, ich bin an einem Punkt wo das erweitern schwieriger
9:20
wird als das vielleicht von Grund auf noch mal neu zu
9:22
entwickeln weißt du also ich mein da, deshalb gibt es ja auch
9:25
Neuentwicklung, weil du an diesen Punkt kommen kannst, dass
9:28
es zeitlich oder vom Aufwand her gesehen.
9:31
Besser ist es, neu zu machen, als irgendwie zu versuchen, da
9:34
noch was reinzufriemeln so in dem was du hast in der Codebasis
9:38
definitiv. Hat man auch schon öfter mal
9:40
erlebt oder kennt man vielleicht auch, hat man gehört.
9:43
Wie auch immer, aber gerade bei bei den Solid ich find das
9:47
lustig weil wie du meintest ne. Man, man wusste das vielleicht
9:52
nicht, oder? Oder wie kann man sowas
9:54
vermeiden und zu dem Zeitpunkt wo ich jetzt meinen Riesen
9:58
payment Service geschrieben hab ne wo ich Milliarden verloren
10:01
hab nein wie gesagt war ja nicht genau das Beispiel ich mir kommt
10:06
das Beispiel nicht mehr richtig in den Kopf aber deswegen hab
10:08
ich jetzt versucht das sozusagen nachzukonstruieren mit einem
10:11
anderen Beispiel aber. Ich, ich kannte zum Beispiel
10:15
Solid zu dem Zeitpunkt noch gar nicht.
10:16
Ne, also diese Prinzipien, beispielsweise ne und
10:19
irgendwann, das fand ich noch ganz lustig, da hatte ich
10:21
irgendwann mal so n Moment, da stand stand ich so ne Runde ne
10:24
mit auch so alten Kollegen irgendwo und dann meinte einer
10:26
so ja und auf jeden Fall solid dies und das und alle so hm ja
10:31
ja ja so solid ja ist auf jeden Fall wichtig danach ne und so.
10:35
Und jeder im Kopf. So was ist solid, verdammt, das
10:38
war ich, das war ich in dem. Moment, und dafür so ja, warte
10:41
mal erst mal aufschreiben, gucken.
10:43
Was soll das eigentlich? Ist so, während du noch Nickst
10:47
im Kreis das Handy rausgeholt, gegoogelt und das war so finde
10:52
ich so lustige Situation ne auch noch mal zum puncto Poster
10:56
Syndrom ich dachte mir in dem Moment natürlich ey du kennst
10:58
mal wieder gar nichts hier, alle anderen kennen das, aber ich
11:01
mein ich hab ja auch genickt so nach dem Motto so ja.
11:03
Ja, auf jeden Fall. Also vielleicht, vielleicht
11:06
waren da ja so 50% der Leute dabei, die auch sich dachten,
11:09
das muss ich mal nachgucken. Ja, sicherlich sicherlich sehr
11:14
witzig, ja, aber kenn ich so ne Situation?
11:16
Man muss natürlich sagen, die Prinzipien die wir jetzt gleich
11:19
erklären werden, also gleich geht es wirklich los, sind ja
11:24
unter dem Namen Solid bekannt, aber was dahinter steckt kennen
11:28
manche vielleicht auch ohne an Solid zu denken oder zu wissen,
11:31
dass das so in Solid alles zusammengefasst ist.
11:35
Also dann das noch mal so als Anmerkung ne, also ich denke,
11:38
dass du die Prinzipien zu dem Zeitpunkt schon kanntest, dass
11:42
man darauf achten sollte, aber vielleicht nicht als diese
11:45
Zusammenfassung und trotzdem stehst.
11:47
Steht man dann in dem Moment da, oh mein Gott, was ist das denn
11:49
jetzt schon wieder euch? Oh mein Gott, da klickt dann
11:52
wirklich so das imposter Syndrom wieder.
11:54
Aber dann kommt er noch dazu, kurz noch bevor wir jetzt ruhig
11:57
reinstarten da kommt er noch dazu, dass man es vielleicht
12:00
kennt, aber nicht anwenden kann so.
12:02
Ja. Der oder denn halt wirklich
12:04
nicht im Hinterkopf hat. Und genau das wollen wir jetzt
12:06
schärfen, denn jetzt geht es los, also kommen wir mal zum
12:10
Solid Prinzip, es ist halt wirklich sehr verbreitet und
12:13
bekannt und es wurde auch schon viel thematisiert, also an der
12:16
Stelle angemerkt, falls du, liebe Zuhörer, liebe Zuhörer
12:19
nach dieser. Grundlegenden Folge heute noch
12:22
Fragen dazu hast, kannst du dich erstens gerne bei uns dann
12:25
melden über die Podcast Mail, ansonsten können wir auch
12:28
empfehlen, einfach mal auf youtube nach dem Prinzip zu
12:30
gucken, da gibt es auch viele Videos, die das erklären und
12:32
veranschaulichen darstellen ist auch immer noch eine coole
12:35
Ergänzung und deswegen jetzt geht es los, Fabi erster
12:39
Buchstabe das S von Solid, wofür steht das?
12:42
Stell dir erstmal vor, jetzt kommt so das es rein ins Bild
12:46
Spam es. Genau, es steht für Single
12:50
Responsibility Principle. Das heißt im Grunde genommen,
12:53
dass eine Klasse jetzt immer wieder bei Klassen eine Aufgabe
12:56
übernehmen soll und auch wirklich nur eine und nicht
13:00
mehrere und das ist, finde ich ganz interessant, weil wenn man
13:06
sich jetzt mal überlegt und jetzt mal jeder auch für sich
13:08
Hand aufs Herz, ist es schon mal vorgekommen, dass man vielleicht
13:11
eine Klasse geschrieben hat, die irgendwie hieß sowas wie.
13:16
Weiß nicht irgendwas XYZ utils xyz Helper was auch immer
13:21
irgendwas ne also irgendwas Manager genau setzt das setzt
13:25
für XYZ irgendwas ein und dann hängen Utils Helper Manager
13:29
hinten dran und jetzt noch mal Hand aufs Herz ist es auch schon
13:33
mal jemandem passiert, dass diese Klasse völlig ausgeufert
13:37
ist und tausende Fachlichkeiten in.
13:41
In einer Klasse oder in einem Pfeil gebündelt hat und wenn ja,
13:45
dann wird immer Hand. Heben ja, also 2.
13:48
Hände sehe ich gerade genau. Also das ist finde ich genau,
13:52
dass der Knackpunkt an diesem Prinzip, weil es geht wirklich
13:56
darum, dass du eine Klasse hast, die sich darum kümmert, um genau
14:01
eine Verantwortlichkeit, also eine oder Fachlichkeit, wie du
14:05
es nennen möchtest und. Und nicht, dass du mehrere
14:08
Sachen ineinander sag. Ich jetzt mal verbandelst.
14:12
Also wenn du jetzt noch mal, weil wir gesagt hatten, wir
14:14
versuchen mal eine Analogie zu geben, angenommen, du hast ein
14:17
Werkzeug, ne und dieses Werkzeug ist ein Multifunktions alles
14:21
Werkzeug, du kannst damit du kannst damit schneiden, sägen,
14:24
schrauben, bohren, du kannst alles machen so.
14:27
Also bohren ist krass. Bis eben wollte ich noch sagen,
14:29
so typisches Schweizer Taschenmesser.
14:31
Ne, das Bohren wäre krasser, das ist noch viel viel.
14:34
Krasser. Damit kannst du wirklich alles
14:36
machen und. Und jetzt geht dir auf einmal
14:38
der Bohrer kaputt und du denkst dir so, ah misten echt blöd, ich
14:43
kauf mir halt wieder dieses super multifunktionale Ding,
14:47
weil es gibt ja auch nur das muss man sich natürlich
14:49
vorstellen, es gibt nur das ne, dann kaufst du dir natürlich den
14:51
Bohrer noch mal, kannst wieder bohren, aber hast dazu natürlich
14:54
noch mal wieder ne Säge und du hast wieder weiß nicht n was hab
14:57
ich gesagt akkubohrer frag mich nicht, ich weiß selber wieder
15:00
was drin war, du hast also quasi alles noch mal doppelt, obwohl
15:03
du ja eigentlich nur den Bohrer gebraucht hättest.
15:06
Ne. So, und jetzt wär es ja viel
15:08
cleverer ne einfach zu sagen ey ich mach n eigenes Werkzeug was
15:11
n Bohrer ist und n eigenes Werkzeug was ne Säge ist und so
15:14
weiter ne Oh Wunder gibt es auch, ist tatsächlich in der
15:18
Realität so und das ist halt genau der Punkt.
15:22
Du willst ja wenn dir irgendwas kaputt geht beispielsweise nicht
15:25
noch mal das Ganze dann sozusagen nachbestellen, in
15:28
diesem Fall ne ja. Das ist ne ganz gute, ne gute
15:32
Analogie. Jetzt kann sich natürlich der
15:34
eine oder andere denken, ja, aber ich möchte so n Schweizer
15:36
Taschenmesser haben, weil da halt alles dran ist und das
15:38
schön kompakt ist. Ja klar, das ist in dieser
15:41
Analogie der Vorteil, aber wenn wir das jetzt mal auf n Code
15:44
Münzen, dieses Beispiel erkennt man, dass es halt
15:47
architekturtechnisch gesehen schon Sinn macht diese
15:51
Verantwortlichkeiten aufzusplitten.
15:54
Ich würd mal als Beispiel was reinhauen, was was vielleicht
15:58
der ein oder andere kennt. Mal angenommen du hast so ne Art
16:01
Report Klasse oder log klasse oder irgendwas mit
16:05
Textverarbeitung ja. Stell dir vor, du erzeugst jetzt
16:09
ne Klasse Report und sagst ja gut was.
16:11
Was muss die jetzt können und du fängst an und sagst na ja ich
16:15
möchte, ich krieg das Halt in einem gewissen Format und möchte
16:19
das jetzt in einem für mein Programm lesbares Format
16:23
formatieren, ne, also du kriegst zum Beispiel jetzt n String rein
16:28
und willst das jetzt aufsplitten in ein Format was du.
16:32
Verarbeiten kannst. Das heißt, du hast so ne
16:34
Formatfunktion zum Beispiel, das heißt Deine Klasse Report hat
16:38
jetzt ne Formatfunktion und bietet die Funktionalität
16:41
formatieren an. Soweit so gut ist eine
16:44
Verantwortlichkeit passt, könnte man jetzt sagen Report der Name
16:47
vielleicht nicht so gut, aber lassen wir das mal so stehen.
16:51
Auf einmal denkst du dir aber, na ja, aber diese diese Formate
16:54
muss ich ja auch mal abspeichern.
16:56
Ich muss ja irgendwie diese Reports ablegen können.
16:59
Ja gut, dann ich hab ne reportklasse, dann werd ich
17:03
jetzt ne safe Funktion einbauen. Klar.
17:07
Da geb ich n Pfad rein, hab meinen meinen formatierten
17:11
Bericht ja sozusagen schon und den kann ich jetzt abspeichern.
17:14
Cool super, ganz Lean, nicht viel Code, kleine Klasse super.
17:19
Hab jetzt aber schon 2 Verantwortlichkeiten drin.
17:22
Einmal das Formatieren und das Abspeichern richtig so und dann
17:27
heißt es auf einmal ja, aber wär irgendwie cool wenn ich über die
17:30
Software diesen Bericht auch an Kollege XY schicken kann, kannst
17:35
du das nicht als Mail oder über über ne API rausschicken.
17:39
Wie auch immer, aber dass du auf einmal noch ne Funktionalität
17:42
send hast und sagst. Na ja gut, dann bereite ich
17:45
jetzt die Daten noch mal auf in ein Format, was ich verschicken
17:48
kann. Ja, so Report ist noch Platz ist
17:52
noch nicht so groß, die Klasse Hau ich da auch mit 3 sind schon
17:54
3 Verantwortlichkeiten, jetzt kann man sich denken ja gut es
17:58
ist aber ne sehr übersichtliche Klasse, das Problem ist aber was
18:02
ist wenn sich das Format ändert wenn du sagst meine
18:05
Formatfunktion ändert sich weil ich intern meine Daten anders
18:08
darstellen möchte, dann ändere ich das Format und gleichzeitig
18:12
wird meine Send. Nicht mehr funktionieren, weil
18:15
ich nicht mehr von der gleichen Datenbasis in vielleicht diese
18:18
zu übertragende Format quasi umwandeln kann.
18:23
Das heißt, du musst dann einfach schon mehrere Funktionen,
18:25
mehrere Funktionalitäten und Verantwortlichkeiten, wie das
18:28
Prinzip ja sagt, Anpassen, deshalb wäre es da, um auch
18:33
Solid einzuhalten, der bessere Ansatz zu sagen, ich splitte das
18:37
einfach in diese Verantwortlichkeiten auf und hab
18:40
zum Beispiel ne formata Klasse. Ich hab ne Art Klasse, die das
18:45
speichern, die Funktionalität und Verantwortlichkeit hab, dass
18:49
ich zum Beispiel dieses Formatieren und das Abspeichern
18:52
der Daten oder das Cent was ich jetzt meinte einfach wirklich
18:56
Kapsel und. Voneinander trenne weil dann
18:59
spielt es nämlich keine Rolle, wenn ich bei avas änder, dann
19:01
ist b davon nicht betroffen, richtig und vor allem könntest
19:05
du auch rein theoretisch in deinem Formata oder wie du den
19:07
genannt hattest ne, also dieser dieser Formatierer nenn ich den
19:10
jetzt einfach mal. Könntest du ja auch verschiedene
19:15
Funktionen einbauen. Zu sagen, ey ich möchte jetzt
19:18
aber zum Beispiel auch, also wenn du es in verschiedene
19:22
Formate formatieren möchtest, weißt du, dann kannst du ja zum
19:25
Beispiel sagen, ey, ich brauch das zum Beispiel fürs Senden,
19:28
brauch ich das oder ich brauch es zum Beispiel fürs Speichern
19:32
oder was auch immer, dann kannst du Format for send machen oder
19:35
Format for for safe oder was auch immer ne also Namen
19:39
austauschbar, aber du weißt was ich meine.
19:42
Das heißt, du hast die Möglichkeit zu sagen, okay, du
19:43
hast etwas, was formatiert für eine bestimmte, also also eine
19:50
Klasse, die sich nur um das Formatieren kümmert, und du
19:53
kannst halt sagen, was formatiert, also wie es
19:55
formatiert werden soll, zum Beispiel genau, es ist auf jeden
20:00
Fall ein sehr guter Punkt und sehr wichtig, dass man dann
20:04
genau diese Aufspaltung macht und.
20:08
Und genau das mein ich auch. Wenn du jetzt zum Beispiel so n,
20:11
sagen wir mal du also was ich am Anfang eingehends meinte, du
20:14
hast ne utils Klasse oder so ne und da haust du erstmal alles
20:18
rein so und denkst dir so ach komm hör mal, ich hab jetzt
20:21
irgendwie ne utils klasse die ach die benutze ich da noch mal
20:24
und dann hast du aber nutzt du diese utils Klasse zum Beispiel
20:27
und du hast ne Funktion da drin Funktion HBC frag mich nicht ne
20:33
und die wird aber per. Perspektivisch in über über die
20:38
Zeit der Alterung der Software, so in der in der
20:41
Implementierungszeit. Je weiter fortgeschritten die
20:44
Implementierungszeit ist, desto höher ist die
20:46
Wahrscheinlichkeit, dass diese Funktion ABC auch an ganz vielen
20:49
Stellen genutzt wird. Und wenn du jetzt aber dann
20:52
dahin kommst und sagst okay ich muss jetzt aber mal, du bist an
20:55
einer Stelle im Code anstelle a und sagst ich muss jetzt
21:00
hierfür, muss ich aber diese Funktion ändern, die Funktion
21:02
heißt. ABC, aber ich geh da mal rein
21:05
ABC, ich änder das einfach mal ne ist natürlich keine gute
21:08
Practice einfach zu sagen ich änder einfach was da drin, aber
21:12
rein theoretisch könnte es ja sein, dass wenn du ABC änderst
21:15
an 8 anderen stellen oder an noch mehr stellen im Code das
21:20
genauso verwendet wird, aber vielleicht nur an dieser einen
21:23
Stelle A, über die ich gerade geredet hab, es wichtig war,
21:25
dass eine, dass etwas anderes passiert, dass die Funktion ABC
21:30
etwas bisschen anders macht, ne? Und das ist natürlich dann
21:36
schwierig, wenn du sagst, ey, also das, das kann natürlich
21:40
fehleranfällig sein zu sagen, ich ändere jetzt hier was und
21:43
alle anderen stellen kriegen diese genau diese gleiche
21:46
Änderung, aber vielleicht ist diese Änderung, die du
21:49
eigentlich haben willst, eine fachlich ganz andere und müsste
21:52
eigentlich in eine ganz andere Klasse, also in Utils 2.
21:56
In utils 2. Genau.
21:58
Also weißt du was ich meine und das ist ja genau.
22:01
Der Punkt zu sagen und ich find das ist sehr sehr wichtig, sich
22:04
immer wieder zu fragen und das kommt heute auch ja immer noch
22:08
vor. Es ist ja nicht so, dass du
22:09
irgendwann sagst, ich weiß sofort, was meine Fachlichkeiten
22:12
sind, auch noch mal Stichwort refactoring, da kommst du ja
22:14
relativ schnell hinzu sagen. OK, warte mal.
22:16
Ich hab jetzt hier was gemacht, aber eigentlich ist das eine
22:20
Fachlichkeit und das ist ne andere Fachlichkeit.
22:22
Das heißt irgendwann vielleicht im Verlaufe dein der
22:25
Implementierung merkst du das sind ja tatsächlich 2
22:28
fachlichkeiten oder vielleicht kristallisiert sich das über die
22:30
Zeit heraus, dass du sagst, früher war es eine, aber
22:33
mittlerweile sind es eigentlich 2.
22:35
Lasst uns das mal aufsplitten. Ne.
22:36
Genau also dieses diese Awareness sag ich jetzt mal zu
22:40
haben. Und zu gucken, also immer daran
22:43
zu denken und vielleicht auch noch mal mit einem anderen Blick
22:46
später auf gleiche Klassen zurück zu gucken und sagen muss
22:49
man die vielleicht auftrennen, sind das mittlerweile vielleicht
22:51
mehr Verantwortlichkeiten als nur eine, wie es mal war.
22:57
Ja, das ist ein guter Punkt, dass genau dafür auch
23:00
refactoring da ist. Und an der Stelle auch noch mal
23:02
die Anmerkung, dass diese Prinzipien, die wir hier
23:05
erklären, ja auch Richtlinien sind.
23:08
Ja, also es heißt nicht, ich muss jetzt jede einzelne
23:11
Funktion in ne eigene Klasse packen, weil das jetzt
23:13
unterschiedliche Verantwortlichkeiten sind.
23:16
So ist es ja nicht, sondern man muss es geschickt clustern und
23:19
wie du meinst herauskristallisieren, was die
23:22
Verantwortlichkeiten sind, wo lohnt es sich es zu splitten und
23:25
wo nicht? Ja also das auch noch mal
23:27
angemerkt ne, nicht dass man so ins Extreme verfällt, das ist
23:30
auch bei den Cleancode 3 haben wir das oft erwähnt, das sind
23:33
Richtlinien und man muss es nicht immer.
23:36
Ins völlige extreme sag ich mal wirklich übertrieben umsetzen,
23:39
weil dann gehst du leider wieder ins Negative von von den
23:42
Benefits her, die bleiben dann aus sag ich mal so genau genau,
23:47
wir haben ja noch 4 Prinzipien, deswegen geh ich mal direkt zum
23:50
nächsten Let's go und zwar bei Solid.
23:53
Das O steht für Open closed principle, also OCP.
23:57
Und besagt im Prinzip, dass wenn ich ein softwaremodul hab, also
24:01
beispielsweise jetzt auch wieder unsere Klasse, dass diese offen
24:05
für Erweiterung sein soll, aber geschlossen für Modifikation.
24:10
Und das ist eigentlich auch relativ gut zu erklären, da
24:13
würde ich nämlich noch mal dein Beispiel aufgreifen, was du
24:16
eingangs quasi gebracht hattest. Vorhin mit mit dem Bezahlen.
24:21
Wie du meintest, so, es gibt eine Bezahlmöglichkeit.
24:23
Ja dann hab ich ne Funktion, die heißt Pay in meiner Payment
24:27
klasse und da bau ich jetzt den Code ein den Ich brauche um
24:31
dieses Pay auszuführen ne und dann kommst du aber zu dem
24:37
Punkt, dass du sagst ja ich muss das jetzt erweitern, es gibt
24:39
jetzt wir binden noch ne Bezahlmöglichkeit an, zum
24:42
Beispiel keine Ahnung das Erste war Kreditkarte und jetzt machen
24:45
wir auf Rechnung. Mhm.
24:47
So ja OK, warte mal. Die Pay Methode ich sehe schon
24:50
da ist die Kreditkartenzahlung drin.
24:53
Ich brauche jetzt auf Rechnung ja gut if Aids wie du meintest
24:56
zum Beispiel so gut OK ist entschieden ich hab jetzt zum
24:58
Beispiel NI Namen was sagt was quasi identifiziert was für ne
25:02
Bezahlung und fertig weiter geht es ja OK wäre aber auch echt
25:07
wirklich cool das Ganze keine Ahnung mit Paypal.
25:12
Paypal zum Beispiel zu bezahlen. So, dann bist du schon bei 345,
25:15
was alles noch mit reinkommt, ne und dann kommst du an den Punkt.
25:19
Was ist wenn jetzt irgendwas in dieser Pay angepasst werden muss
25:23
was alle betrifft, was nur eine Bezahlmöglichkeit betrifft, dann
25:27
kommst du halt in Teufelsküche wie man so schön sagt, du musst
25:30
extrem aufpassen, dass du die anderen Bezahlmöglichkeiten
25:34
nicht kaputt machst, sage ich mal.
25:37
Wenn du jetzt zum Beispiel eine ergänzt oder bei einer was
25:40
abändern muss, die anderen nicht betroffen sind.
25:42
Du musst dir überlegen, welche sind alle betroffen von meiner
25:45
Änderung in der Pay Methode und das ist richtig tricky
25:49
irgendwann und auch wirklich ein heißes Ding so also das ist
25:53
gefährlich und deswegen sagt dieses Prinzip, du musst dafür
25:57
sorgen, dass du erweiterbar bist.
26:00
Also du kannst neue Bezahlmöglichkeiten reinbringen,
26:03
aber geschlossen für Modifikation.
26:05
Du darfst nicht die bisherigen Bezahlmöglichkeiten beeinflussen
26:09
damit, und das kann man denn eigentlich sich auch ganz gut
26:12
vorstellen, indem du sagst, ich hab jetzt nicht nur ne klasse,
26:14
wo ne Pay drin ist, sondern ich erzeuge für jede
26:18
Bezahlmöglichkeiten hab ich eine eigene Klasse, die eine Pay
26:22
implementiert, das heißt ich hab jetzt zum Beispiel ne Abstrakte.
26:26
Payment Klasse. Die wird zum Beispiel abstrakt
26:28
mit einer Methode Pay und ich implementiere jetzt meine
26:31
Bezahlmöglichkeiten davon und implementiere die Pay und kann
26:35
denn abhängig von der gewählten Bezahlmöglichkeit die richtige
26:38
Pay Methode aufrufen. Ich hoffe man konnte das mir
26:42
folgen. Wie gesagt, die haben ne
26:45
Triggerwarnung gegeben. Im Endeffekt so ne Art einfach
26:48
ne Art Interface, was sozusagen implementiert wird dann am Ende.
26:52
Und dann hab ich den Vorteil, wenn ich jetzt sage, bei der
26:54
Rechnung muss ich zum Beispiel irgendwie wie ich ne Rechnung da
26:59
noch mit ranhänge oder wie ich die Ausliefer wie auch wie auch
27:01
immer, also wirklich was rechnungsspezifisches, muss ich
27:03
in der Pay jetzt anders aufrufen oder?
27:06
Kommt, wird komplett abgewandelt, dann betrifft das,
27:10
betrifft das aber nicht meine anderen Bezahlmöglichkeiten,
27:13
weil die Pay Methode ja quasi extrahiert ist.
27:15
Sozusagen. Ja, und das ist halt eine schöne
27:18
Sache dabei. Das finde ich zum Beispiel noch,
27:21
um noch mal vielleicht eine kleine Analogie noch mal da zu
27:24
lassen, falls das jetzt vielleicht zu verwirrend oder zu
27:29
objektorientier lastig war. Was auch immer.
27:33
Will nicht sagen, dass man sich versteht.
27:35
Ich habe es fantastisch verstanden.
27:37
Aber. Wenn du jetzt zum Beispiel,
27:39
sagen wir mal, du hast du den Rechner und du willst jetzt zum
27:41
Beispiel deinen deinen Speicher aufstocken, dann kannst du ja
27:44
sagen okay, ich möchte meinen Speicher erweitern, so
27:46
demzufolge kannst du zum Beispiel hast du einen extra
27:48
Slot dafür und kannst halt eben einen neuen Speicherriegel
27:51
einsetzen, relativ einfach super ohne Probleme.
27:55
Ne. Und es ist ja nicht so, dass du
27:57
erst zum Beispiel sagst, ey, ich muss jetzt aber noch irgendwie
28:00
mein Motherboard irgendwie auseinander schrauben, da noch
28:03
was dran löten sozusagen oder vielleicht den vorherigen
28:06
Speicherriegel, sozusagen die, die die Schnittstelle, wo ich es
28:09
drauf stecke, sozusagen verändern, weil der gar nicht
28:11
passt oder so ne, also diese Modifikation sollte ich mein,
28:15
das ist selbsterklärend bei einem Rechner, dass man das
28:18
nicht tut, ne, aber? Genau darum geht es halt eben zu
28:22
sagen. OK, ich kann es erweitern, aber
28:24
ich will es nicht modifizieren, weil angenommen du modifizierst
28:27
es würden ja vielleicht deine alten Speicherriegel gar nicht
28:30
mehr passen und dann hast du auch nichts gewonnen.
28:33
Und der Vorteil ist natürlich, wenn ne Pay Methode wegfällt,
28:36
zum Beispiel jetzt noch mal in dem Beispiel, dass du sie
28:39
einfach. Entfernen kannst und musst nicht
28:42
in deiner vorherigen globalen Pay Methode gucken.
28:45
Wo muss ich jetzt überall Codezeilen löschen um diese Pay
28:48
Methode rauszukriegen und funktionieren die anderen noch
28:51
zum Beispiel? Also du hast halt diese
28:53
Erweiterbarkeit, aber natürlich auch den Umkehrschluss, dass du
28:56
Sachen auch wieder sehr gut, weil sie so Gekapselt sind,
28:59
entfernen kannst. Richtig genau also wie gesagt,
29:04
ist natürlich auch wieder. Eine Richtlinie sozusagen ist
29:08
jetzt kein kein Must have. Es ist aber immer gut.
29:12
Wie gesagt, bei solchen Dingen daran zu denken und sowas im
29:16
Hinterkopf zu haben und zu sagen, okay ist es denn
29:19
vielleicht sinnvoll in diesem Moment, es nach diesem Prinzip,
29:23
nach diesem o Prinzip, dem OCP oder Open closed principle
29:28
vielleicht zu betrachten? Beziehungsweise könnte man es
29:31
einbringen, ist es an der Stelle sinnvoll.
29:33
Das ist ja sozusagen immer der Gedanke, der dann mitschwingen
29:38
könnte, sollte vielleicht um es eventuell dann besser zu machen
29:41
oder vielleicht genau das zu vermeiden, was du eingangs
29:44
beschrieben hast, sozusagen das Problem an der Sache, an der
29:47
Sache. Ja, du hast es schon gesagt, es
29:50
ist so Awareness ne, dass man einfach das im Hinterkopf hat
29:52
und dran denkt dann. Das wird schon dafür sorgen.
29:56
Allein wenn man davon gehört hat und das immer im Hinterkopf hat,
29:58
sorgt schon dafür, fortan bessere Softwarearchitekturen zu
30:04
erstellen. Definitiv auf jeden Fall, also
30:07
zumindest aus unserer Erfahrung her, wo wir uns damit, also als
30:10
wir angefangen haben, uns damit auseinanderzusetzen, hat das
30:12
dafür gesorgt, bessere Softwarearchitekturen erstellen
30:14
zu können. Ich finde, was auch auf jeden
30:16
Fall hilft ist oder was mir auf jeden Fall auch öfter mal
30:20
geholfen hat, ist einfach mal zu sagen, es gibt so ein Prinzip
30:23
und ich versuche mir jetzt aber mal.
30:24
Vom Beispiel zu nehmen, um es einfach mal nach zu
30:26
programmieren, weil ich finde, es sind es sind immer noch 2
30:29
Sachen auf der einen Seite, das kenne ich, das okay mehrere
30:33
Sachen, Entschuldigung, das ist quasi so eine Art Kette, dass du
30:37
sagst auf der einen Seite kenne ich überhaupt dieses Prinzip,
30:40
wenn ja Check super Sache, dann weiß ich wie es funktioniert
30:44
okay alles klar Check habe ich es einfach mal ausprobiert um zu
30:47
fühlen. Wie das wirklich funktioniert,
30:50
wie es sich auch anfühlt, im Code ne.
30:53
Und da ist es dann einfach hilfreich, einfach mal zu sagen,
30:56
OK, ich nehm mir mal n Beispiel Programmier das einfach mal und
31:01
kann sozusagen live mitkriegen, wie dann sozusagen.
31:06
Wie dieses Prinzip dann angewendet aussieht, selbst mal
31:09
programmiert und so weiter ne, also das ist halt einfach auch
31:13
noch mal hilfreich klingt finde ich immer sehr trivial zu sagen,
31:15
ja gut, du weißt doch wie es geht, aber einmal programmieren
31:19
einmal selber n Beispiel sag ich jetzt mal auf die Beine stellen
31:23
und dann ist es noch mal n bisschen was anderes, zumindest
31:25
geht es auf jeden. Fall.
31:27
So auf jeden Fall das da geh ich mit, so kommen wir mal zum
31:31
dritten Solid l. Das ist das lisco Substitution
31:36
Principal und da muss ich sagen das ist das Prinzip von den 5
31:41
was ich persönlich damals am schwierigsten fand.
31:46
Zu verstehen und zu verinnerlichen.
31:48
Deswegen würde ich da auch direkt mit einer Analogie
31:50
starten, nicht auf n Codebeispiel gehen, in der
31:54
Hoffnung, dass man es dann n bisschen besser greifen kann.
31:57
Ich. Bringe danach n Codebeispiel.
31:58
OK, sehr gut. Dann machen wir es diesmal so
32:01
rum und zwar möchte ich, liebe Zuhörer, liebe Zuhörer, dass du
32:04
dir mal vorstellst, wieso eine universelle Steckdose aussieht
32:07
und wie man sie quasi verwendet. Und dann stell dir vor, du hast
32:11
jetzt verschiedene Elektrogeräte wie?
32:14
Ja, was habe ich hier gerade ein Laptop, Ladekabel, ich habe
32:18
einen Kaffee, also eine Kaffeemaschine noch in der
32:20
Küche, Staubsauger, Staubsauger auch eine super Sache.
32:24
Also du hast so verschiedene Elektrogeräte mit ganz
32:27
unterschiedlichen Anwendungsfällen, die aber die
32:30
gleiche Steckdose verwenden, das heißt du kannst jedes Gerät in
32:35
diese Steckdose stecken und verwenden.
32:37
Also der Laptop lädt, die Kaffeemaschine kann Kaffee
32:40
machen und der Staubsauger saugt so.
32:43
Und das ist im Prinzip dann lisco Substitution Principle
32:47
konform, das heißt jedes Gerät ist untereinander ersetzbar mit
32:53
dieser Steckdose. Du kannst erst das Laptop
32:56
Ladekabel ranstecken, dann ziehst du es raus wenn der
32:58
Laptop geladen ist, dann steckst du die Kaffeemaschine ran,
33:01
zapfst dir einen Kaffee. Ziehst sie wieder raus, machst
33:03
einen Staubsauger ran und saugst dein Arbeitszimmer
33:05
beispielsweise. Das heißt, sie erfüllen alle die
33:08
gleichen elektrischen Anforderungen, um mit dieser
33:11
Steckdose verwendet werden zu können.
33:14
Was ist jetzt jedoch, wenn du beispielsweise ein
33:17
amerikanisches Gerät hast, was eine andere Spannung benötigt,
33:22
dann funktioniert das eben nicht mehr, weil wenn.
33:26
Ja, keine Ahnung, bis zum Kurzschluss, keine Ahnung was
33:28
passieren kann, aber es verstößt halt gegen dieses Prinzip, weil
33:31
du die Geräte nicht mehr willkürlich, was heißt
33:34
willkürlich, also wie du möchtest einfach austauschen
33:36
kannst, weil dieses amerikanische Gerät eine andere
33:40
Spezifikation der elektrischen Anforderungen hat und das würde
33:44
gegen dieses Prinzip verstoßen. Du kannst es halt nicht mehr
33:47
frei austauschen, es ist halt nicht kompatibel am Ende.
33:52
Ich mein das System in dem Sinne und so Steckdose ich mein das
33:55
fängt ja rein theoretisch genau bei der Steckdose schon an, aber
33:58
selbst wenn du den Stecker gleich machen würdest, würde ja
34:02
wahrscheinlich trotzdem irgendwas nicht funktionieren,
34:04
da bin ich kein Elektrotechniker, ich weiß nicht
34:05
genau was passieren würde, wenn man mehr oder weniger Volt dann
34:09
da reinstecken würde, du meintest ja Kurzschluss fängt
34:12
der Staubsauger da an zu brennen, ich weiß.
34:14
Es nicht versaugt richtig krass. Nein, wir werden es mal nicht so
34:19
auf die Elektrotechnik Ebene hin, weil davon haben wir keine
34:21
Ahnung. Aber da genau das ist ne gute
34:23
Anmerkung selbst. Also meistens ist ja so, dass
34:26
der Stecker dann schon gar nicht passt.
34:27
Aber selbst wenn der Stecker passt, würde es halt nicht
34:31
funktionieren, weil du halt von einer anderen Spezifikation
34:34
ausgehst. Bei dem Gerät genau als die
34:36
anderen vorher genannten. Richtig.
34:38
Und es ist ja im Endeffekt so. Also diese Ersetzbarkeit, worum
34:42
es ja in diesem Prinzip geht, ne?
34:46
Da ist es. Es ist, das bedeutet in dem
34:48
Fall, dass wenn ein Programm ne, also in dem Fall sozusagen jetzt
34:53
die Steckdose soll, nicht merken ob es quasi ne Oberklasse oder
34:59
ne Unterklasse verwendet, ne also es ist egal was verwendet
35:03
wird, es muss funktionieren an dieser Schnittstelle sozusagen
35:06
ne ja und da geht es quasi. Also das das ist ja im Endeffekt
35:11
genau diese diese Ersetzbarkeit. Aus Programmsicht natürlich als
35:15
Programmierer oder Programmieren weißt du natürlich, klar, ich
35:18
weiß jetzt, was ich da verwende, aber das Programm weiß es zum
35:21
Beispiel, dann sollte es nicht wissen, ne, also kleines
35:25
Beispiel, wenn man jetzt zum du hast zum Beispiel so so Vögel so
35:31
ne vogelklasse ne und? Es ist ja ein richtiges
35:35
Lehrbuchbeispiel, finde ich. Gut, aber.
35:37
Pass auf, weil ich finde, ich finde das wirklich gut, weil in.
35:40
Im Normalfall was. Was können Vögel?
35:42
Vögel können fliegen, ne so das weiß man so und das können ja
35:47
eigentlich alle Vögel so, aber es gibt ja zum Beispiel Vögel,
35:51
die können das dann doch nicht, ne, also sind doch nicht alle
35:54
so, ja, aber man denkt ja erstmal ne, also wenn er also
35:56
angenommen man fängt jetzt an und sagt Ey ich brauch jetzt
35:59
vielleicht für irgendein Game oder so irgendeine irgendeine
36:01
Klasse ne vogelklasse weil ich will irgendwie Gegner haben, die
36:05
Fliegen ne so und. Und es soll aber auch irgendwie
36:08
auf der anderen Seite auch wieder sehr realistisch sein.
36:11
So, dann fängst du an, denkst du so, ja, ich habe ja die und die
36:13
Vögel kämpfende Vögel kennt man, fliegen draußen die ganze Zeit
36:16
nur rum. Ultra aggressiv, immer genau.
36:19
Aber so, dann hast du halt auf einmal einen Pinguin.
36:22
So ein Pinguin kann halt vielleicht nicht fliegen, also
36:25
er kann nicht fliegen, aber vielleicht im Game auch nicht so
36:28
und dann hast du halt ne also ne du hast jetzt ne Klasse
36:33
erstellt. Vogel und dieser, diese
36:35
Vogelklasse, diese Oberklasse, diese Superklasse, die kann halt
36:39
die Funktion fliegen, so fly ja so und dann hast du jetzt diesen
36:45
Pinguin, der ja sagt Ey, ich bin aber ein Vogel, also kann ich ja
36:49
auch Fly aufrufen, weißt du so und dann hast du das Problem,
36:54
dass du aber an der Stelle ja eigentlich nicht fliegen kannst.
36:59
Also angenommen es würde ein String zurückkommen, so was wie
37:02
ja ich kann fliegen, ich bin ein Vogel, dann würde ja beim
37:06
Pinguin genauso zurückkommen. Ja, ich kann fliegen, ich bin
37:08
ein Vogel. So was nicht stimmt.
37:10
Was nicht stimmt. Genau so, das heißt, das wäre ja
37:12
in dem Fall dann falsch so, also würdest du dich ja dann
37:16
vielleicht hinstellen und sagen naja, aber ich möchte ja genau
37:19
in diesem Fall vom Fliegen möchte ich dann vielleicht eine
37:22
Exception werfen, das heißt, ich überschreibe die Funktion.
37:25
In der Klasse Pinguin und sage ja gut, pass auf ich wenn wenn
37:31
Fly aufgerufen wird, dann werf ich einfach ne Exception und
37:34
sage ja das funktioniert aber nicht weil n Pinguin kann halt
37:36
nicht fliegen, sorry. Ja, so weißt, dann ist natürlich
37:39
der Pinguin an der Stelle fein raus und sagt so, ich hab
37:41
mitgeteilt ich kann nicht fliegen, richtig, aber was ist
37:44
das Problem wenn ich jetzt in meiner Software mit genau dieser
37:47
Vogelklasse arbeiten möchte? Genau das ist nämlich das Ding.
37:50
Angenommen, du hast jetzt dein, also du du.
37:53
Arbeitest immer mit Vögeln und gehst davon aus.
37:56
Okay du hast einen Vogel, so und wie gesagt, das Programm soll
37:59
nicht wissen, ist es eine Oberklasse oder eine Unterklasse
38:01
eine Subklasse so, das heißt das Programm sagt ich nehme mir halt
38:06
irgendwas was ein Vogel ist und ruft darauf fly auf und erwarte
38:09
dann okay ich kriege jetzt, dass der Vogel fliegt, genau dass der
38:13
Vogel fliegt beziehungsweise ich meinte ja so, du kriegst
38:15
vielleicht einen String zurück um sich das einfacher
38:16
vorzustellen, da steht drin ich kann fliegen so das erwartet das
38:19
Programm und was aber bei einem Pinguin passiert es fliegt eine
38:22
Exception so. So, das heißt, das Programm kann
38:25
in dem Moment vielleicht gar nicht damit umgehen, weil man,
38:27
weil man sich als Programmierer oder Programmiererin gedacht
38:30
hat, ja, da muss ich eine Ausnahme machen und denkt aber
38:33
an einer anderen Stelle nicht, vielleicht ist man selbst für
38:35
diese Stelle gar nicht zuständig, dass da ja dann eine
38:38
Exception fliegt, die gar nicht behandelt wird und es gar nicht
38:41
vorgesehen ist, dass da eine Exception behandelt wird.
38:44
So, und dann hast du halt genau das Problem, und das kann man im
38:48
Endeffekt, oder? Wenn man sagt okay ich möchte
38:50
aber dieses Lsp, also so heißt das Prinzip ja abgekürzt, möchte
38:54
ich konform sein, dann wäre die Lösung an der Stelle zu sagen
38:58
okay, du hast eine klasse Vogel und du hast vielleicht aber auch
39:02
noch eine Klasse Flying oder oder fliegbarer Vogel Flying
39:08
Bird nenne ich das jetzt mal, der sozusagen, also ein Vogel,
39:11
der Fliegen kann, diese klasse, und die also ein fliegender
39:16
Vogel ist. Natürlich ein Vogel, das heißt
39:18
das. Also fliegender Vogel ist eine
39:21
Unterklasse von Vogel. So weit, so gut.
39:23
Wenn du jetzt aber zum Beispiel irgendeinen anderen Vogel hast,
39:26
wie zum Beispiel ein Rabe oder so ne also oder eine Möwe, wie
39:29
zum Beispiel bei unserem Flappy Buddy Programmierwettbewerb.
39:31
Genau das ist ein reales Problem.
39:33
Leute, ja genau, auch wenn es bei uns keine Pinguine gibt.
39:37
Aber angenommen, Du hast jetzt zum Beispiel Rabe oder Möwe ne
39:42
als Vogel und das sind beides Vögel, die wiederum Unterklassen
39:46
von von einem fliegenden Vogel sind.
39:48
Das heißt, Rabe ist ein fliegender Vogel und ist aber
39:52
auch ein Vogel. So genau.
39:53
Und jetzt kommt noch ein Pinguin und sagt, ein Pinguin ist ein
39:56
Vogel, was ja bedeutet, dass im Endeffekt der fliegende Vogel
40:00
die Funktion fly hat und demzufolge Rabe oder eine Möwe
40:07
auch, aber der Pinguin nicht, weil die klasse Vogel hat.
40:11
Diese Funktion fliegen nicht so, demzufolge muss oder oder hat
40:16
jeder Vogel 2. Zwar nicht die Möglichkeit,
40:19
fliegen aufzurufen, als Funktion aber n fliegender Vogel und der
40:24
Pinguin selber, der nur vom Vogel, dann sag ich jetzt mal
40:27
abhängig ist oder ne Unterklasse vom Vogel ist der dem kann man
40:31
dann vielleicht noch so ne Art schwimmen oder so verpassen, ne?
40:36
Genau, und dadurch ist quasi die die basisklasse Vogel ja nicht
40:40
verletzt am Ende durch die Unterklassen.
40:43
Wenn ich jetzt die Basisklasse in meiner Software verwende,
40:46
weil ich denn nicht mehr sagen kann Vogel Punkt fliegen oder
40:51
fly was du meintest, dann kann es nicht mehr passieren, dass
40:54
ich da auf einen Pinguin komme, der aber nicht fliegen kann,
40:56
weil ich das Halt aufgeteilt habe und das ist halt der
40:59
entscheidende Punkt dabei. Genau also.
41:02
Also du kannst dich natürlich hinstellen und sagen, OK,
41:04
Pinguin ist jetzt ne sub klasse auch von flyingbird, aber dann
41:07
macht man ganz. Andere Sachen, aber dann kannst
41:09
du, kannst es aber in deiner Software differenzieren einfach
41:12
und kannst damit dieses Prinzip einhalten.
41:14
Genau also wie gesagt noch mal an der Stelle, es ist n bisschen
41:17
komplizierter und ich hab auch damals gebraucht das so wirklich
41:20
zu verinnerlichen und zu verstehen.
41:21
Ich hoffe wir haben es gut rüber gebracht also ich konnt ihr gut
41:24
folgen, ansonsten wenn es Fragen dazu gibt lieber zur lieber zur
41:29
gerne ne Mail dann werden wir es noch mal vertiefen.
41:32
Oder noch mal kurz zur Steckeranalogie zurück sprechen.
41:34
Oder noch mal noch mal die Steckdosenanalogie.
41:38
Ansonsten würde ich sagen, gehe ich mal zum vierten Prinzip, es
41:41
kommen ja noch 2. Stimmt so, dann sind wir bei dem
41:45
I und das ist das Interface Segregation Principle, also dass
41:51
man quasi spezifische Schnittstellen verwenden soll
41:55
anstatt riesige Interfaces. Wo wir auch wieder beim Thema
41:59
sind, super klasse oder super Interface wo du alles also
42:03
wirklich wie wenn wir noch mal die Stecker nehmen, da kannst du
42:06
einfach alles anstecken und auf der anderen Seite kann auch
42:08
alles rausgehen und du hast so n riesen Konverter da, der kann
42:11
alles so ne aber keiner weiß mehr wirklich was da drin
42:13
abgeht. Oder oder stell dir ne ne ne ne
42:18
universelle Fernbedienung vor, eine Fernbedienung die alles
42:21
kann, die hat einfach 100 Knöpfe und du kannst alles damit
42:24
steuern. Hast du mal so eine gesehen?
42:26
Ich hatte wirklich mal so ne Universalfernbedienung, die
42:28
kannst du dir ja kaufen, gab es früher ja immer so für alle.
42:31
Fernseher so ne und ich hab zu Ende mal irgendwie bei einem
42:34
Kumpel oder so gesehen dachte was ist das denn Alter und
42:37
eigentlich brauchst du ja am Ende nur irgendwie wieviel.
42:40
So 5 Tasten oder so. Ich, ich tatsächlich hab ich mal
42:43
ne Fernbedienung gesehen, die konntest du umdrehen und die hat
42:45
auf der anderen Seite auch noch Knöpfe gekauft.
42:48
Das ist aber das ist halt n perfektes Beispiel, das ist
42:51
eigentlich die perfekte Analogie die wir gerade gefunden haben,
42:53
weil wie du schon so schön meintest, du hast vielleicht.
42:57
Nächstes Programm vorheriges laut, leise Mute vielleicht
43:01
noch. Also du brauchst vielleicht ne
43:01
Handvoll Knöpfe, hast dann aber so n universelles Ding mit 100
43:05
Dingern, also 100 Knöpfen, wo du theoretisch sogar noch NDVD
43:09
Player bedienen könntest. Weißt du?
43:11
Falls man noch weiß, was du hast zu Hause.
43:14
Und da ist halt genau die Frage, wäre es nicht besser eine
43:17
spezialisierte Fernbedienung und so wie man sie auch zum
43:20
Fernseher dazu bekommt? Zu haben die wirklich die auf
43:24
die Funktion des Fernsehers eingeht und nicht noch 1000
43:27
extra Funktionen, die quasi unjusted sind noch drauf zu
43:31
haben. Und genau darum kümmert sich das
43:33
Prinzip. Ist auf jeden Fall auch ein
43:37
super spannendes Prinzip. Ich habe das auch tatsächlich
43:39
auch schon öfter selber erlebt, dass man irgendwie man erstellt
43:43
ein Interface und sagt, Ja, komm, ich habe jetzt.
43:46
Also das ist aber auch wieder so n so n so n Work and progressing
43:49
weißt du, du fängst an und sagst OK ich hab ein Interface und
43:53
mein Interface hat 2 Funktionen ne und wenn du sagst OK ich
43:58
möchte jetzt dieses also irgendwie dieses Interface
44:01
implementieren, dann hab ich jetzt zum Beispiel, also wie
44:05
nehmen wir noch mal das Payment Beispiel ne und du sagst OK.
44:09
Du hast ein Interface mit Pay drin, als Beispiel ne und jede
44:13
einzelne Bezahlmöglichkeit muss ja irgendwie Pay implementieren,
44:16
vielleicht auf eine andere Art und Weise ne, dann hast dann
44:20
hast du ja im Endeffekt den, du hast es ja relativ, das ist ein
44:26
schlankes Interface, ein Payment Interface sozusagen ne wo nicht
44:29
wirklich viel dabei ist. Aber wenn du jetzt anfängst und
44:32
sagst Ey, aber da kommt jetzt zum Beispiel noch dies rein und
44:35
das rein und jenes und hast du nicht gesehen, dann.
44:38
Hast du vielleicht im Payment Service 1?
44:40
Nutzt du 2 Funktionen von 20 im Payment Service 32 nutzt du dann
44:47
was weiß ich sagen wir mal 10 Funktionen und in dem anderen
44:50
auch noch mal 10 aber eigentlich sind mindestens immer 10
44:54
Funktionen die im Interface eigentlich insgesamt verfügbar
44:58
sind ungenutzt und dann? Ne, wie gesagt, das ist manchmal
45:02
auch so. N work and progress, dass man
45:03
dann vielleicht irgendwann es es baut sich auf in deiner Software
45:07
und du denkst dir, irgendwann gibt es nicht vielleicht
45:09
irgendwie Gemeinsamkeiten wo man sagt das ist ein Interface was
45:15
rein theoretisch richtig Sinn macht, ne also dass man die
45:18
Interfaces sozusagen dass du, dass du einfach vielleicht 3
45:21
Interfaces aufsplittest, weil zum Beispiel eine Funktion,
45:24
nämlich die Pay Funktion, das ist wirklich die Funktion, die
45:27
jedes. Jeder Payment Service verwendet,
45:31
also ist das auch wirklich ein Interface, ein eigenes
45:34
Interface, ne? Ja, hast du da vielleicht ein
45:38
kleines Minimalbeispiel, was wir noch so geben könnten, weil wir
45:41
jetzt überall immer so Beispiele hatten?
45:43
Fällt dir gerade was ein? Also wenn du jetzt zum Beispiel
45:46
sagst, nehmen wir mal Roboter, kommen ja jetzt gerade, sind ja
45:50
voll im Kommen, ne. Mit KI und können dir was
45:52
abnehmen. So ja.
45:53
Geil das hau raus das Beispiel. So, und jetzt hast du zum
45:57
Beispiel, sagen wir mal in in in Lagerristen ne.
46:03
Weil ich glaube, in in, in vielen so Logistikzentren oder
46:06
so werden ja auch mittlerweile Roboter eingesetzt, die Pakete
46:09
durch die Gegend tragen. Und du hast jetzt so.
46:12
Ich war letztens kurz off topic war ich in so einem Diner, wo
46:16
mir hier dieser so n Roboter das Essen an Tisch gebracht hat.
46:19
OK, und wie fandst du das? Das war voll witzig, aber du
46:22
hast doch das als Beispiel nehmen.
46:23
Das ist auf jeden Fall, das kann ich nicht zeugen.
46:25
Aus der Realität OK, cool. Also du hast, du hast n Roboter,
46:29
also sagen wir mal du hast n Restaurant in dem.
46:32
Du Servierkräfte hast also menschliche Servierer,
46:36
Serviererin und Kellnermäßig und Kellner, also Roboter, Kellner,
46:41
so Roboter, Kellner klingt wieso ein Film, ey die Rückkehr der
46:47
Roboter, Kellner auf jeden Fall so dann diese beiden hast du und
46:51
dann hast du zum Beispiel einmal den den Arbeiter sozusagen und
46:55
einmal den Roboter so und beide könnten ja rein theoretisch auf
47:00
jeden Fall arbeiten. Also so, und dann hast du aber
47:05
zum Beispiel noch den Punkt, dass du sagst okay, aber also
47:08
ein Arbeiter, der möchte ja auch oder der Mensch, der möchte
47:12
auch, der muss ja auch essen, so was wie eine Essenspause machen,
47:16
also dass du halt einfach sagst, Mittagspause komm, ich gehe
47:18
essen, das braucht der Roboter aber nicht, der muss aber
47:21
vielleicht laden, was auch immer, vielleicht schafft er
47:23
auch den ganzen Tag, aber sagen wir mal, du hast im Endeffekt
47:26
eine Klasse, die das ist sozusagen klasse Arbeiter so im.
47:31
Im Großen und Ganzen. Und dieser Arbeiter muss
47:34
arbeiten können, logischerweise, die Funktion braucht er, weil er
47:37
arbeiten soll und er muss essen. So und jetzt hast du aber zum
47:41
Beispiel den Roboter wieder und wenn der Roboter aber ein
47:45
Arbeiter ist, genauso wie ein Mensch ein Arbeiter sein kann in
47:48
diesem Restaurant, dann kannst du ja rein theoretisch auf dem
47:53
Arbeiter wieder, weil der Arbeiter die Funktion Work und
47:56
Eat hat, also er darf arbeiten und kann essen.
47:59
Könntest du ja rein theoretisch, wenn der Roboter ein Arbeiter
48:01
ist, auch auf dem Roboter die Funktion eat aufrufen.
48:05
So und jetzt hast du natürlich wieder das so n bisschen
48:08
ähnliches Prinzip was wir vorher also vorhin hatten, ne andere
48:12
also die Subklasse macht was anderes oder?
48:15
Oder reagiert vielleicht anders weil dann vielleicht ne
48:17
Exception geworfen wird und da steht dann drin als Exception
48:21
Message Roboter müssen nicht essen so ja aber.
48:26
Hier geht es ja auf einen anderen Punkt hinaus und zwar,
48:28
dass du die Interfaces oder die Oberklassen oder wie du es
48:31
nennen möchtest ist. In dem Fall ist ein Interface
48:34
würde ich jetzt mal sagen, schlanker machst ne, das heißt
48:37
im Endeffekt spezifischer. Genau spezifischer finde ich
48:40
gut, also du hast mehr, aber spezifischer, das heißt im
48:43
Endeffekt hast du das Interface workable ne wenn wir jetzt von
48:47
Worker oder Arbeiter ausgehen, das heißt also.
48:49
Arbeitend, wenn es auf Deutsch machen willst oder so und
48:53
eatable so. Das heißt du hast sozusagen n
48:55
Interface. Was sagt OK es ist möglich zu
48:58
essen und n Interface was sagt es ist möglich zu zu.
49:02
Arbeiten so und bitte an der Stelle nicht übersetzen als n
49:06
essbarer Mitarbeiter sagen genau, aber ich weiß was du
49:10
meinst. So, und dann genau.
49:12
Und dann hast du ja zum Beispiel kannst Du sagen, OK der der
49:14
Mensch, ne der ist zum Beispiel, also der ist.
49:18
Rockable und die und der Roboter ist halt nur rockable so und
49:24
demzufolge hast du dann den Effekt, dass der Mensch 2
49:28
Interfaces implementiert, also zum Beispiel einmal das
49:30
Interface für Essen und das Interface für Arbeiten und der
49:34
Roboter hat nur das Interface für arbeiten, was aber auch
49:37
gleichzeitig in deiner Software bedeutet, dass wenn du sagst,
49:40
ey, ich möchte jetzt alle losschicken, angenommen sagen
49:43
wir mal, du hast eine kleine Simulation von dem Restaurant
49:46
und. Und du möchtest in deiner
49:47
Simulation alle Arbeiter losschicken in
49:50
Anführungsstrichen? Dann kannst du ja sagen okay,
49:53
ich nehme alle meine Instanzen von Workern sozusagen und lass
49:58
die arbeiten so und dann kann ja ein Worker, ist ja zum Beispiel
50:03
entweder ein Mensch oder ein Roboter, aber wenn du jetzt
50:05
sagst, schick mal bitte alle worker in Anführungsstrichen zum
50:11
Essen. Also beziehungsweise die die
50:14
auch essen können. Die, die sozusagen das eatable
50:18
Interface implementieren, dann funktioniert das, aber die
50:21
Roboter werden sozusagen gar nicht dann bedient an der
50:24
Stelle, weil die das ja gar nicht überhaupt nicht in ihrer
50:27
Funktionalität dann drin haben, oder halt dieses eatable
50:30
Interface gar nicht implementieren.
50:32
Genau. Und.
50:35
Jetzt kann man sich natürlich denken, OK, das sind jetzt 2
50:37
Eigenschaften, sozusagen, das Krieg ich schon noch irgendwie
50:39
verwaltet. Ne, das wär so n Grundgedanke
50:41
wenn Gedanke, wenn man quasi immer weitergeht und sagt, nee
50:45
ich brauch so ne Prinzipie nicht, das geht schon, das passt
50:47
schon so, jetzt sagst du aber irgendwann jetzt hab ich aber
50:50
auch noch Mitarbeiter die in der Pause draußen rauchen gehen, so
50:53
ne dann will ich noch wissen wer raucht von denen zum Beispiel
50:56
oder? Du baust die Aufgaben ein.
50:59
Wer bringt zum Tisch, Wer bereitet die Getränke zu, wer
51:02
geht in die Küche und so weiter und es kommen immer mehr
51:04
Eigenschaften rein in dieses Interface und es wird quasi so
51:09
riesig wie unsere Fernbedienung. Aber es gilt halt nicht für
51:11
jeden. Weil der, der draußen die Teller
51:14
abräumt, muss ja nicht noch Funktionen implementieren, wie
51:17
er Getränke zubereitet. Jemand, der nicht raucht, muss
51:19
nicht wissen, wie die Funktion aussieht, um rauszugehen und zu
51:21
rauchen. Weißt du also, das ist ja genau
51:24
das der Punkt den du meinst, weil wenn man sich so denkt ja 2
51:27
Funktionen Come on es wird 100 Pro irgendwann mehr und dann ist
51:30
es genau richtig diese spezifischen Interfaces zu
51:33
verwenden um dann auch spezifisch drauf zugreifen zu
51:36
können am Ende oder unterscheiden zu können,
51:39
richtig. Im Endeffekt hast du ja auf
51:41
jeden Fall ein gutes Beispiel. Im Endeffekt hast du ja, wenn du
51:43
es in deiner Software siehst, irgendwann Objekte, auf denen du
51:46
irgendwas aufrufen willst. Und du willst ja wissen, auf
51:50
welchen Objekten kann ich denn was aufrufen und es soll dann
51:53
auch so funktionieren. Ne, und damit du das besser auch
51:57
differenzieren kannst zwischen diesen Objekten auch
51:59
unterscheiden kannst, hast du halt eben dann auch
52:02
spezifischere Interfaces sozusagen.
52:04
Ja, genau. Ja, cool, erklärt Fabi, vielen
52:09
Dank dafür. Lass uns mal zum letzten Prinzip
52:11
kommen, wir sind auch schon n bisschen fortgeschritten in der
52:13
Zeit, aber wir müssen auf jeden Fall es noch unterbringen, das
52:16
wär jetzt so richtig mies und das nächste erfahrt ihr in der
52:19
nächsten Folge. OK, das D in Solid steht für
52:24
Dependency Inversion Principle und das finde ich sehr spannend
52:27
und auch sehr wichtig ist ne sehr gute Sache und im Prinzip
52:32
geht es um Dependency Injection als Lösung dahinter.
52:36
Aber wie kann man sich das Ganze vorstellen, wenn man sich jetzt
52:40
vorstellt, man hat zum Beispiel eine Anwendung, wo du so eine
52:43
Business Geschäftslogik drin hast, die halt wirklich intern
52:46
in deiner Software quasi regelt, wie gewisse Sachen umgesetzt
52:51
werden, verarbeitet werden und. Je mehr ich zu den Eingabe zum
52:57
Beispiel. Ich hab jetzt ganz klassisch
52:58
eingabeverarbeitung Ausgabe ne, nehmen wir mal so das Eva Ding
53:02
und diese Verarbeitungslogik ist riesig, da passiert unglaublich
53:05
viel. Wir haben sehr viele Eingaben
53:07
und jetzt erzeug ich aber Abhängigkeiten von diesen
53:10
Eingaben und bin halt so unglaublich verzwickt.
53:14
Oder man stellt sich das vor, so keine Ahnung im Webbereich, wo
53:18
ja auch viele unterwegs sind. Ich habe halt so eine API, das
53:21
ist meine Eingabe und die Verarbeitung ist wie ich auf der
53:24
Datenbank mit diesen Daten arbeite und wenn ich jetzt aber
53:27
so unglaublich verzwickt und Verwurstelt nenne ich es mal mit
53:31
der Eingabe bin, dann kriege ich halt riesenprobleme wenn ich das
53:35
ganze quasi durch diese Abhängigkeiten verändern will,
53:38
weil ich dann an allen Stellen wieder eingreifen muss.
53:42
Kannst, kannst du mir folgen? Definitiv.
53:45
Also ich hab halt das Problem, dass es nicht mehr flexibel ist,
53:48
dass es vor allem nicht mehr testbar ist, weil das ist jetzt
53:51
n riesen Punkt. Dieses Prinzip sag ich mal
53:55
fördert unglaublich die Testbarkeit, da können wir
53:57
gleich noch mal drauf eingehen und ich kann es auch nicht mehr
54:00
gut erweitern am Ende, weil ich halt diese Kopplung hab.
54:04
Und wie schaffe ich es jetzt diese Eingabe und Verarbeitung
54:08
voneinander zu entkoppeln? Und genau da greift halt die
54:11
Dependency Injection und magst du, hast du vielleicht so ein
54:15
Minimalbeispiel? Also ich finde wir können ja das
54:18
ruhig mit dieser API und Datenbank ruhig weitermachen,
54:21
weil ich glaube das ist so ein Bereich wo viele unterwegs sind
54:24
im Webbereich wie man jetzt so eine Dependency Injection
54:28
verwenden könnte dafür. Also im Endeffekt kannst du, ich
54:33
hoffe ich kann das Beispiel jetzt richtig aufgreifen was du
54:36
meinst. Also angenommen du hast jetzt
54:40
eine eine eine sagen wir mal Anwendung und diese Anwendung
54:46
hat auf jeden Fall, also hat eine Zugriff auf eine Datenbank
54:51
so ne so und dann ist diese Datenbank zum Beispiel einfach
54:55
festgeschrieben in diesem Programm, das heißt du hast so.
54:58
Sozusagen irgendwie einen Service.
55:00
Also sagen wir mal, du gehst über eine API und du hast in
55:03
dieser API eine Anfrage und du hast irgendwie einen Service,
55:07
der diese Anfrage verarbeitet und sagt zum Beispiel okay ich
55:10
muss jetzt aber diese diesen Request in meine Datenbank
55:13
schreiben oder Daten aus dieser Datenbank rausholen, genau, und
55:16
jetzt hast du in deinem Service zum Beispiel eine Datenbank
55:19
instanziiert so weil dieser Service sagt zum Beispiel okay
55:23
ich brauche eine Datenbank und wenn du jetzt aber zum Beispiel
55:26
sagst okay ich. Habe jetzt zum Beispiel eine My
55:29
SQL Datenbank, die ich über diesen Service anspreche.
55:34
Dann wird jeder request immer nur gegen eine My SQL Datenbank
55:38
gehen und wenn du aber jetzt zum Beispiel sagst ich möchte jetzt
55:41
aber eigentlich gegen eine andere Datenbank gehen, weil ich
55:43
noch eine andere habe, wie willst du das machen weil du
55:46
immer nur diesen einen Service hast der.
55:51
Quasi wo drin, wenn dieser Service hochgefahren wird oder
55:54
existiert, dann hat er eine feste Instanz von einer
55:56
Datenbank oder einen festen Zugriff auf eine Datenbank,
55:59
besser gesagt eine Connection dazu.
56:00
So und wenn du jetzt aber zum Beispiel sagst, ich möchte das
56:04
ganze Injekten sozusagen, also dependency Injection nutzen,
56:10
dann gibst du quasi die Datenbank von außen rein, das
56:13
heißt im Endeffekt sagst du okay ich möchte diesen User Service
56:16
haben mit dieser Datenbank. Das bedeutet, dass du im
56:21
Endeffekt nicht sagst, okay, ich habe jetzt eine eine feste
56:24
Datenbank, sondern ich sage diesem diesem Service, dem sage
56:32
ich pass auf, ich brauche jetzt Daten, diese Daten brauche ich
56:36
aus einer Datenbank und ich gebe dir mit, welche Datenbank das
56:40
ist, von der du diese Daten holen sollst beziehungsweise wo
56:44
wo du die Daten reinschreiben sollst.
56:46
Das ist sozusagen der kleine Unterschied.
56:50
Ja, und das kannst du ja halt auch auf allen Ebenen packen.
56:54
Also das war jetzt quasi die Funktion mit dem
56:57
Datenbankzugriff. Du kannst es aber auch genauso
57:00
eine Ebene höher packen. Wie sieht denn deine Rest api,
57:03
deine Calls, deine Requests aus und was passiert in deiner
57:07
Software? Da kannst du das ja genauso auf
57:09
der Ebene einziehen, dass du sagst, ich möchte ja nicht, dass
57:12
jeder request genau wenn ich den Entgegennehme schon quasi.
57:17
Quasi in sich selbst tragend. Die Implementierung hat, wie ich
57:21
auf der Datenbank arbeite, also wie der Service aussieht, weil
57:24
dann ist jeder Request an den Service gekoppelt, da haben wir
57:28
wieder ne Kopplung und wenn du jetzt aber sagst ich hab zum
57:31
Beispiel ne Art Controller, ist so n klassischer klassische
57:34
Klasse klassische Klasse dafür für so die für die Request die
57:39
sich nur darum kümmert auf welchen Calls nehm ich denn was
57:43
entgegen? Und gebe da den Service auch
57:47
noch mal rein. Dann hab ich das auch noch mal
57:49
entkoppelt und das ist auch dependency Injection, dass ich
57:51
sage, dieser Controller instanziiert sich keinen Service
57:55
und ist damit exakt gekoppelt an diesen Service, sondern ich gebe
57:59
von draußen einen Service rein, der dafür sorgt auf diese
58:04
Request zu reagieren und der ist austauschbar.
58:07
Ja, genauso wie dein Beispiel. Ich habe dann den Service, der
58:11
wiederum von außen die Datenbank bekommt, damit die Datenbank
58:14
austauschbar ist, dass es halt nicht in sich selbst
58:17
instanziiert und implementiert ist.
58:20
Und das ist halt n Riesenvorteil, weil wir auch
58:22
meinten, Testbarkeit angenommen, ich möchte jetzt sagen wir mal
58:29
den Controller testen. Ja, ja, also ich will jetzt
58:32
einfach, ich tue jetzt so, als wenn n request reinkommt und ich
58:35
möchte wissen, ob ich auf 200 mit 200 OK antworte, weil alles
58:39
OK war oder nen 404 beispielsweise und ich will das
58:43
jetzt testen und hab jetzt aber in dem Controller selbst diesen
58:47
Service implementiert, da muss ich diesen ganzen Rattenschwanz
58:50
irgendwie in diesen Test reinbringen, damit ich den
58:52
Abtesten kann. Wenn ich jetzt aber diesen
58:55
Service von draußen in den Controller gebe, dann kann ich
58:58
ja nen. Sag ich mal n gemobbten Service
59:01
da reingeben und simulieren wie der reagiert und kann mir so
59:06
viel besser Testfälle bauen, dass ich zum Beispiel sag, wie
59:09
sieht der Request aus, alles klar, ich tu mal so als wenn ich
59:12
in der Datenbank jetzt den Eintrag finde und ah OK 200 OK
59:16
geht zurück super der Test funktioniert jetzt tue ich so
59:19
als wenn ich den Eintrag nicht finde ja OK 404 beispielsweise.
59:25
Wenn ich das aber so nicht machen müsste, dann bräuchte ich
59:27
den richtigen Service. Dann bräuchte ich die richtige
59:29
Datenbank, um irgendwie nach oben wieder zu bekommen.
59:31
Ob der User jetzt da drin war oder nicht beispielsweise, und
59:35
das ist halt das coole an Dependency Injection und das ist
59:37
halt auch das D in Solid am Ende.
59:40
Ja, richtig. Also ich finde Dependence
59:43
Injection ist an sich auch ein relativ großes Thema, wenn man
59:45
da jetzt noch mal, wie du ja eingangs auch schon meintest,
59:48
wenn es bestimmte Themen gibt, über die wir noch mal ein
59:50
bisschen genauer eingehen sollen, Liebe zuhören, lieber
59:52
zuhören, dann schreibt uns auf jeden Fall gerne wie gesagt über
59:55
unsere Podcast Mail oder auch auf unseren Plattformen, wie
59:57
gesagt, alles in den Show Notes verlinkt, um das Ganze noch mal
1:00:01
abzuschließen, um das vielleicht noch mal auch ein bisschen, also
1:00:04
dieses D in Solid, um da noch mal ein kleines Bild vor Augen
1:00:08
zu rufen. Ja.
1:00:09
Ich meine. Guck mal, es geht ja jetzt auch
1:00:12
langsam wieder Richtung Sommer. Das bedeutet langsam ne, so
1:00:15
dauert ein bisschen noch, aber man sag ich jetzt mal
1:00:18
urlaubsplanung ist vielleicht ist real so und angenommen du
1:00:24
als Mensch jetzt ne hast du bist eine Instanz und wirst erzeugt
1:00:30
so und wenn du jetzt keine Dependency Injection hast und
1:00:34
sagst OK ich möchte jetzt aber zum Beispiel mit einem Flugzeug
1:00:37
fliegen so. So, dann wird dir zum Beispiel
1:00:40
eingeimpft, ne in in deiner DNA, du darfst nur von Hamburg
1:00:44
fliegen, weil du sozusagen in dir selber den Flughafen
1:00:50
instanziierst. Also.
1:00:52
Ne, also eine Instanz anlegst und das ist immer Hamburg
1:00:56
beispielsweise und nie was anderes.
1:00:58
Das bedeutet also, du könntest zwar nach Angeboten gucken und
1:01:02
sagen, Oh guck mal, ich könnte vielleicht von Berlin fliegen
1:01:04
oder von München oder was auch immer, geht nicht, weil du
1:01:06
darfst, genau, du darfst nur von Hamburg fliegen und von nirgends
1:01:10
woanders. Wenn du jetzt aber zum Beispiel
1:01:11
sagst, ey, ich könnte jetzt aber die dependency Flughafen
1:01:16
Injekten. Dann hast du die Möglichkeit zu
1:01:19
sagen, ich gucke erstmal, welchen Flughafen ich denn
1:01:22
überhaupt ansteuern möchte. Und wenn ich mir einen
1:01:25
ausgesucht habe, dann nehme ich diesen und gebe ihn sozusagen
1:01:30
von außen rein. Also ich sag jetzt mal
1:01:32
gedanklich, du kaufst dir die Tickets und bekommst deine
1:01:35
Tickets und checkst dir in die Tasche so genau und dann weißt
1:01:38
du ja, aber okay ich, ich kann mich entscheiden, weil ich
1:01:42
erstmal sage, welcher Flughafen und dann nehme ich diesen
1:01:46
Flughafen anstatt zu sagen, ich nehme erst den Flughafen und
1:01:49
dann gucke ich mal was von da fliegt und wo es hingehen könnte
1:01:52
so. Und das ermöglicht dir halt
1:01:55
diese ganze Implementierung drumrum.
1:01:57
Oder sagen wir mal in deinem Beispiel, diesen ganzen Ablauf,
1:02:00
sei es das. Stellen der Tickets, den Flug
1:02:02
buchen oder auch zum Beispiel, was vor Ort am Flughafen
1:02:06
passiert, was geführt bei jedem Flughafen gleich ist.
1:02:08
Ja, aber wenn ich dann immer von Hamburg aus gehe, bringt mir das
1:02:11
nichts. Genauso kann ich den Flughafen
1:02:12
von draußen reingeben, also was wir mit inject Minen, falls das
1:02:16
nicht ganz klar ist. Ist ja im einfachen übertragenen
1:02:19
Sinne n Eingabeparameter in einer Funktion zum Beispiel
1:02:22
richtig oder in den Konstruktor einer Klasse richtig.
1:02:25
Und dann hab ich halt den Vorteil, dass ich den Rest der
1:02:28
der Funktion nicht anpassen muss, vielleicht für so kleine
1:02:31
spezifische Sachen. Beispielsweise Flughafen Hamburg
1:02:35
parke ich direkt vor Ort, bei Flughafen Berlin kann ich nicht
1:02:37
direkt vor Ort weißt du so so flughafenspezifische Sachen, die
1:02:41
sich unterscheiden können, würden dann die ganze Funktion
1:02:43
beeinflussen, was aber total unnötig ist, weil vor Ort muss
1:02:46
ich ja trotzdem mein Gepäck aufgeben, durch ne
1:02:48
Sicherheitskontrolle gehen und in n Flieger steigen, was vor
1:02:51
allem wieder gleich ist. Weißt du deswegen das ist n
1:02:53
cooles Beispiel abschließend finde ich sehr gut danke dir.
1:02:58
So genau, und damit sind wir ja quasi jetzt einmal durch die 5
1:03:01
Prinzipien durch Solid ist auf jeden Fall super spannend und
1:03:07
wie gesagt immer eine wichtige Sache das im Hinterkopf zu
1:03:10
behalten. Man muss nicht strikt danach
1:03:12
arbeiten, es ist auch überhaupt nicht schlimm mal irgendwann in
1:03:16
in der Entwicklung seiner Software zu sehen um Mensch das
1:03:20
das sind jetzt aber zum Beispiel mehrere Fachlichkeiten, da muss
1:03:23
ich jetzt zum Beispiel mal was auf splitten, da muss ich
1:03:25
vielleicht mal wieder was refact an, aber.
1:03:27
Alles kein Problem, wenn man denn zum Beispiel einfach auch
1:03:31
mal so bestimmte Infos mal im Hinterkopf hat und und danach
1:03:34
vielleicht so seinen eigenen Code oder seine Software, in der
1:03:36
man arbeitet, scannt. Sag ich jetzt mal ne ja und dann
1:03:40
kann es einfach sag ich mal nachhaltig besser werden.
1:03:44
Ja, also auch noch mal ganz kurz abschließend die Tech Home
1:03:48
Message. Ich würde noch mal ganz, ganz
1:03:50
kurz durchgehen, noch mal so zur Zusammenfassung.
1:03:53
Also solid ist. Im Prinzip sind 5 Prinzipien für
1:03:56
jeden Buchstaben 1. Wir haben das S mit Single
1:03:59
Responsibility Principle im Prinzip eine Klasse, eine
1:04:03
Aufgabe, eine Verantwortlichkeit, dann haben
1:04:06
wir das Open Close principle, was im Prinzip besagt sei offen
1:04:10
für Erweiterung und geschlossen für Modifikation.
1:04:13
Drittens war das lisco Substitution principle, was im
1:04:16
Prinzip die Ersetzbarkeit von den Subklassen beinhaltete, das
1:04:21
Vogelbeispiel. Ich hoffe, man kann sich noch
1:04:23
dran erinnern mit den Pinguinen, viertens war Interface
1:04:26
Segregation Principle, was im Prinzip sagt nicht die
1:04:29
universelle Fernbedienung, sondern speziell für deinen
1:04:32
Fernseher, das heißt lieber spezifische Interfaces statt
1:04:35
riesige Schnittstellen und jetzt zum Abschluss hatten wir
1:04:38
dependency Inversion Principle mit der Dependency Injection.
1:04:43
Was ja im Endeffekt sagt, diese Abhängigkeiten, die man hat,
1:04:46
lieber auf Abstraktionsebene packen und nicht auf konkrete
1:04:49
Implementierung, wo du ja gerade das Flugbeispiel gebracht
1:04:52
hattest. Wenn ich implementiere in meiner
1:04:54
buchungsfunktion Flughafen oder so.
1:04:57
Start ist immer Hamburg ungünstig.
1:04:59
Richtig, ganz genau so sieht es aus, gut zusammengefasst, Kino,
1:05:03
dann sind wir eigentlich auch, würde ich sagen, durch wie
1:05:07
gesagt bei. 2 genaueren Fragen weitere weiterführenden Podcast
1:05:13
folgenden Themen schreibt uns einfach an.
1:05:16
Ansonsten danke Tino fürs für die Folge, hat Spaß gemacht und
1:05:21
war sehr cool. Wir haben versucht es möglichst
1:05:24
kurz zu halten und es ist wieder länger geworden als man denkt
1:05:26
wie? So immer.
1:05:28
Es sind aber auch 5 Prinzipien man so.
1:05:32
Genau. Und ansonsten würde ich sagen,
1:05:34
bewertet gerne den Podcast. Das würde uns mega freuen.
1:05:38
Empfiehlt ihn auch gerne weiter, wenn ihr sagt das ist ein Hammer
1:05:42
cooler Podcast. Genauso könnt ihr uns auch
1:05:44
unterstützen mit einem kleinen Spenden Link gibt es alles unten
1:05:47
in den Shownotes einfach mal reinschauen und mal durchlesen,
1:05:50
mal reinschnuppern sozusagen, ansonsten bleibt mir nichts
1:05:53
anderes übrig als zu sagen bis zum nächsten Mal, also bis zur
1:05:57
nächsten Woche. Wir hören uns habt einen schönen
1:05:59
Tag, deine Cordon balis gemeinsam besser.