Latest / Coding Buddies | Tech & Dev-Mindset / #127 Dependency Injection - Das unterscheidet Juniors von Pros

Transcript

#127 Dependency Injection - Das unterscheidet Juniors von Pros · Coding Buddies | Tech & Dev-Mindset

0:00
Ich zum Beispiel jetzt einfach immer meinen Kaffee schwarz
0:02
trinke. Du bist ja so ein Milchtrinker,
0:05
aber ich sehr. Irgendwie ne Beleidigung mach.
0:09
Das weiß ich so nicht. Nein, nein, nein, obwohl ich
0:11
trotzdem. Milch trinke selber Milch,
0:14
trinke Coding Buddies, Dein Podcast rund um
0:18
Softwareentwicklung und aktueller Tech News.
0:20
Herzlich Willkommen. Halli Hallo und herzlich
0:35
Willkommen zur neuen Folge des Cody Buddies Podcasts.
0:37
Schön, dass du wieder eingeschaltet hast, deine
0:39
Gastgeber und wie soll es anders sein, meine Wenigkeit, der Tino
0:43
und der fantastische Fabi, der mir hier schon wieder virtuell
0:46
gegenüber sitzt. Fabi, ich begrüße Dich zur neuen
0:49
Folge. Was geht ab?
0:50
Tino, Tino, Wie geht's, wie steht's?
0:53
Danke für alles, super für die nette Anmoderation mal wieder du
0:59
schmeichelst. Ja, also man braucht jetzt so
1:02
ein paar Konstanten. Weißt du so, wenn schon immer
1:04
ein anderes Thema in der Podcast Folge, dann sollte ich zumindest
1:07
die Anmoderation gleich machen. So ein Wiedererkennungswert
1:10
weißt du, man muss dazu sagen. Du machst es ja aber so, dass
1:13
also du machst es ja auch immer ne, es ist ja nicht so, als
1:16
würde man das irgendwie so. Weißt du so vom irgendwie von
1:19
der Platte einspielen, das ist ja immer wieder live neu
1:23
performt. Nein, also treue Zuhörerinnen
1:27
und Zuhörer merken, dass ich es immer ein bisschen anders
1:29
betone. Also es gibt da schon
1:32
Variationen, aber geht's dir gut, Tino Jo alles ist alles fit
1:38
bei mir, soweit der Stress nimmt so langsam ein bisschen ab sag
1:43
ich mal so die Sommerzeit, diese stressige hat man ja so gesagt,
1:47
also Stress in Anführungszeichen ist natürlich schön, immer was
1:50
los, ist aber auch schön wenn immer wieder so ein bisschen
1:52
mehr Ruhe einkehrt und wie sieht's bei dir aus, Jo Jo?
1:55
Ich will mich nicht beklagen. Das ist gut.
1:59
Klar, das. Ist gut, das ist n gutes
2:01
Zeichen. Aber bevor wir heute richtig
2:04
loslegen, weil wir haben heute n cooles Thema, denn das ist n
2:06
Community Thema was ich gewünscht wurde wo wir heute
2:09
drauf eingehen wollen, möchte ich vorher mich aber noch beim
2:14
Oliver bedanken für die Podcast Spende Oliver Herzlichen Dank
2:18
Wir haben uns mega gefreut vielen vielen vielen Dank dafür
2:20
aber das das er hat uns sehr vielen Dank.
2:23
Und er hat uns auch mit so tollen Attributen.
2:27
Belegt, wie cool und immer bestens gelaunt.
2:29
Also das ist schön, das freut uns natürlich vielen, vielen
2:34
Dank auch dafür, das ja hat auf jeden Fall ein Schmunzeln, ein
2:40
Lächeln in unser Gesicht gezaubert.
2:41
Direkt wieder gute Laune, ne Fabi.
2:44
Auf jeden Fall. Ja, ansonsten liebe zuhören,
2:46
Liebe zuhören. Falls du auch dir denkst,
2:48
Mensch, cooler Podcast. Die Jungs möchte ich
2:50
unterstützen in ihrem Vorhaben, aber.
2:52
Das freut uns dann sehr, wenn das dein Vorhaben ist.
2:54
Den Link dazu findest du, wie man den Shownotes dann schon mal
2:56
vielen Dank für den Support. Ja, vielen Dank und auch vielen
2:59
Dank an den ganzen Support, den wir bisher schon bekommen haben
3:02
und dann möcht ich auch noch mal quasi so allgemein da draußen
3:05
bei. Sein, der hab ich.
3:07
Richtig toll. Vielen vielen dank Tino das
3:10
Thema. Du hast ja gesagt wo du sich
3:11
gewünscht, es geht um Dependency Injection heute ja.
3:18
Quasi ein ein, ich sag mal, ein Thema, wo man in der
3:21
Softwareentwicklung gar nicht drumherum kommt.
3:22
Ja, wir hatten es. Ja, so n bisschen angerissen bei
3:25
unserer Design Pattern Folge zum Thema Singleton, weil wir gesagt
3:30
haben OK, Singleton hat ja einfach definitiv Nachteile die
3:34
es mit sich bringt und dass da oftmals dependency Injection der
3:40
bessere Weg ist, den man da gehen kann.
3:42
Ja. Und hatten ihr Angebot.
3:44
Nee, wenn ihr Bock habt zu dem Thema machen wir ne Folge.
3:47
Und genau das kam auch. Also vielen Dank für die
3:50
Nachrichten und hier ist die Folge.
3:53
Genau sie ist sie lebt. Und Dependency injection ich,
3:59
ich glaube, manche würden wahrscheinlich sagen, das ist
4:01
ein Thema für für Anfänger, sozusagen ich, ich weiß es gar,
4:07
ich kann es gar nicht richtig sagen, weil ich glaube, ich bin
4:10
damit nicht sofort. Beim Start in der
4:15
Softwareentwicklung mit konfrontiert gewesen, aber ich
4:18
weiß nicht wie das heutzutage ist.
4:20
Wie gesagt, war ja bei uns auch ein bisschen Holprigatino, von
4:23
daher kann es ja vielleicht sein, dass andere da generell
4:26
ein bisschen schneller sind, auch so vom vom von der
4:29
Lernkurve her. Aber die Penancy Injection an
4:32
sich ist ja auch eine Art Entwurfsmuster, könnte man es
4:35
nennen. Es ist aber unabhängig jetzt von
4:37
unserer Design Pattern Reihe was wir die wir gemacht haben, weil
4:39
es sozusagen nicht unter diese Design Pattern nicht in diese
4:42
Sparte, sage ich jetzt mal mit reinfällt genau und es geht im
4:48
Endeffekt darum, dass wenn du wir sind, aber trotzdem in der
4:52
Objektorientierung unterwegs, das heißt wenn du Objekte hast,
4:57
dann. Haben mehr Objekte oder Klassen,
5:00
sag ich jetzt mal. Haben ja meistens irgendwie
5:01
Abhängigkeiten zu anderen Teilen aus der Software, die du
5:05
schreibst. Und diese Abhängigkeiten kann
5:08
man auf verschiedene Art und weisen eben irgendwie im Objekt,
5:13
ich sag mal verankern oder mitgeben und bei Dependency
5:16
Injection ist es ja, wie der Name schon sagt, dass diese
5:18
Abhängigkeit, also diese dependency halt eben injiziert
5:22
wird, ne also injected wird. Ja.
5:25
Da hast du ja schon 2 gute Wörter gesagt.
5:27
Einmal dieses mitgeben oder verankern, das trifft es ja
5:30
schon ganz gut, weil diese beiden Möglichkeiten habe ich ja
5:32
im Prinzip, wie ich Abhängigkeiten definieren kann.
5:36
In meiner Klasse entweder ich veranker es wie du es so schön
5:39
meintest, dass es halt hart da drin gekapselt ist, sozusagen ne
5:44
und n fester Bestandteil ist innerhalb meiner Klasse oder
5:47
mitgeben ist das schöne Wort, wenn ich sage ey du brauchst das
5:50
und das zukünftig für deine Aufgaben hier, nimm mal so weißt
5:54
du ich geb dir das jetzt mal mit arbeite damit, mach das Beste
5:58
draus. Ich stell mir das immer so.
6:00
Weißt du, wenn du so. Das Real Life ne so hast ohne
6:05
Dependency Injection, dann ist das ungefähr so.
6:08
Du kannst dir das ungefähr vorstellen, so angenommen guck
6:10
mal das das machen wir beide, wir stehen morgens aufgehen zur
6:12
Kaffeemaschine und ziehen uns n Kaffee so ich hab damit weniger
6:16
n Problem weil ich zum Beispiel jetzt einfach immer meinen
6:19
Kaffee schwarz trinke, du bist ja so milchtrinker aber ich hab
6:22
sehr. Irgendwie ne Beleidigung
6:24
gemacht. Das weiß ich so nicht.
6:27
Nein, nein, nein, obwohl ich trotzdem Milch trinke.
6:31
Selber milch. Trinker mit Milch, Trinker ja
6:36
ne, also alles gut, keine Beleidigung, nur n kleiner
6:40
Angriff, dass man Kaffee nicht mehr Milch trinkt Spaß, aber
6:43
stell dir vor du hast so ne Kaffeemaschine und willst dir so
6:45
nen schönen Cappuccino machen ne und du sagst ja OK ich will den
6:47
jetzt mit Kuhmilch und dann. Sagst du aber morgen, also am
6:53
nächsten Tag sagst du ey ich will den aber jetzt mit
6:55
hafermilch ne und wenn du jetzt keine Dependency Injection
6:58
hättest bei deiner Kaffeemaschine ne, dann wäre es
7:01
so, dass du theoretisch 2 Kaffeemaschinen bräuchtest,
7:03
nämlich einmal ne Kaffeemaschine mit Milch, ne, also mit Kuhmilch
7:06
und eine mit Hafermilch so und im im im absoluten Worst Case
7:11
müsstest du dir, wenn die Milch alles ne neue Kaffeemaschine
7:13
kaufen oder weil sie dich du kennst ja wahrscheinlich auch
7:18
noch die guten alten CD Player von damals.
7:21
Ja, also absolut war ne geile Zeit mit Anti Schock, die man
7:26
sogar in ne Hosentasche stecken konnte.
7:28
Na ja gut, die waren krass, die waren krass.
7:29
War richtig krass, aber auch da wäre es da da als also so diese
7:34
Analogie oder der Vergleich, dass du halt für jede CD, ja die
7:37
du irgendwie hören willst, wieder einen eigenen CD Player
7:40
bräuchtest, weil du halt einfach die CD wird da reingebaut, die
7:43
kannst du nicht wechseln, ne ja das ist sozusagen das wäre die
7:48
Situation. Und jetzt kannst du dich
7:50
natürlich hinstellen und sagen, ja, Fabi, das sind aber ganz
7:52
schön realitätsferne Beispiele und ich würd sagen, Sie sind
7:56
auch aus gutem Grund sehr realitätsfern.
7:59
Weil man es so einfach nicht machen würde.
8:02
Ja, ist richtig, man kann sich das auch so vorstellen.
8:09
Das ist gar nicht so realitätsfern, wenn du dir
8:12
einfach mal aktuelle Smartphones anguckst und du zum Beispiel
8:15
sagst, ist der Akku fest verbaut oder kann ich n Akku
8:18
austauschen? Wäre ja auch mal so ein so ein
8:20
Gedankenspiel, weil dependency Injection nach dem Prinzip
8:25
müsste ich ja sagen okay ich habe ein Handy und ich gebe ein
8:28
Akku dazu und den verwende ich für dieses Handy, damit es
8:32
läuft, wenn er fest verbaut ist. Dann habe ich nämlich genau
8:34
dieses verankert, was du meintest.
8:36
Das heißt der Akku ist fester Bestandteil des Handys und ich
8:42
kann ihn halt nicht wechseln, sondern der da drin ist.
8:45
Ist der Akku des Handys und wenn der kaputt geht habe ich ein
8:47
Problem. Also jetzt für den Line ne.
8:50
Natürlich kann ich das Handy aufmachen und den Akku tauschen,
8:52
aber es ist nicht mehr wie früher unsere gute alte Nokia
8:55
3310 Zeit wo du hinten mal die Schale abgemacht hast die
8:58
sowieso ständig abgefallen ist und du den Akku einfach
9:01
rausnehmen konntest. Ne das wär so auch der
9:04
Unterschied und ich find halt diese Analogien und Beispiele
9:07
immer sehr gut, deswegen gefallen mir deine auch sehr gut
9:10
mit dem CD Player, zum Beispiel weil man daran einfach erkennt,
9:13
dass du ja Konzepte auch versuchst.
9:15
Zu übernehmen sozusagen auch in der Softwareentwicklung, ja.
9:18
Vor allen Dingen auch so was das Konzept.
9:20
Bewährt hat so ja. Genau, ja, auf jeden Fall.
9:24
Aber also deswegen ist halt ne das was du meintest.
9:27
Du kannst es halt von außen reingeben, ne bei einem CD
9:30
Player wie man ihn kennt nimmst du halt ne CD, Pack sie rein wie
9:33
zum Beispiel auch den Akku den man dann vielleicht wechseln
9:35
kann. Du kannst die CD wechseln, du
9:36
kannst vielleicht einfach bei einer normalen Kaffeemaschine
9:39
sag ich jetzt mal die halt eben auch Cappuccino Fisch ist ist
9:41
meine übrigens nicht. Die mag ich nicht, aber komisch
9:46
so als Milchtrinker. Ja, schon n bisschen, der aber
9:53
auf jeden Fall. Kannst du da theoretisch.
9:56
Eigentlich brauchst du ja nur irgendwie, sag ich jetzt mal ne
9:58
Art so Schlauch, wo du dann halt dir die Milch anzapfen kannst.
10:01
Wo du also egal ist, welche Art von Milch dann am Ende
10:04
reinkommt, ne und das ist halt im Endeffekt so das Prinzip von
10:08
Dependency Injection, dass man einfach sagen kann, OK, du hast
10:10
halt eben dein Objekt ne und kannst eben diese Abhängigkeiten
10:14
zu etwas anderem was du brauchst für dein Objekt, was da drin
10:18
verwendet wird eben von außen reingeben und das ist halt.
10:24
Also die Penancy Injection an sich.
10:26
Ich fand das ganz interessant, weil mich hat das am Anfang
10:29
total verwirrt irgendwann als ich damit mal in so ne Berührung
10:31
gekommen bin, hatte mal n Alter ist wirklich schon länger her,
10:35
Kollege irgendwann mal gesagt ja hier inversion of control ne und
10:38
ich dachte mir so oh Gott ey was ist das jetzt schon wieder ne
10:41
klingt. Krass.
10:42
Das ist richtig krass, aber Inversion of Control ist ja
10:46
eigentlich auch nur wie sagt man, also ist das ist das
10:49
Prinzip und die Penancy Injection ist eine Verwendung
10:53
des Prinzips, kann man das so sagen?
10:55
Umsetzung. Ja, und im Endeffekt ist es ja
10:58
nichts anderes, ne. Ja, was dabei ganz witzig ist,
11:02
weil es ja auch es vielleicht auch dem einen oder anderen Mal
11:06
begegnet, dass es so n bisschen das Hollywood Prinzip ist.
11:10
Nach dem Leitsatz Don't Call US, We will Call you.
11:14
Das find ich auch sehr witzig. Weil das genau das
11:18
widerspiegelt. So ne.
11:19
Also du musst jetzt nicht da anrufen, sondern die melden sich
11:22
bei dir. Die Infos werden schon zu dir
11:24
kommen, dann wenn es soweit ist sollte es soweit sein.
11:30
Genau also Inversion of Control die Kontrolle umkehren ja genau,
11:35
ich find das klingt immer super crazy, weil ich mich genau immer
11:38
gefragt hab, also dieses. Ich find, das ist so abstrakt.
11:41
Weißt du, du sagst OK, du kehrst die Kontrolle um und ich hab
11:44
mich immer ganz am Anfang hab ich mich immer so gefragt, was
11:47
soll denn das heißen, die Kontrolle umkehren, das klingt
11:50
irgendwie so weißt du, du bist dann so irgendwie in nem
11:52
Programmflussdenken und denkst dann so fließt das jetzt in die
11:55
andere Richtung zurück oder was also was heißt Kontrolle
11:58
umkehren weißt du also ich ich weiß nicht ob ob das für dich
12:01
auch mal so n Verständnisproblem war einfach nur von diesem.
12:05
Von von diesem Naming her weißt du, weil es heißt ja einfach,
12:08
Kontrolle. Hattest du da mal n Problem mit
12:10
ich? Also ich fand es immer sehr sehr
12:11
komisch das zu greifen. Na, ich hatte am Anfang oft das
12:18
Problem damit, dass ich mich mal gefragt hab, warum das Ganze,
12:21
also warum Kontrolle umkehren, weil irgendwie macht es doch
12:25
Sinn das Ganze zu Kapseln. So ne.
12:27
Also ich hab jetzt n Objekt und das braucht n anderes Objekt um
12:30
davon Funktionen aufzurufen beispielsweise ja.
12:33
Dann war es für mich früher immer so.
12:34
Ja, warum soll ich das jetzt irgendwie von draußen reingeben?
12:36
Ich brauch das ja nur in diesem Objekt, da sozusagen ne, also
12:39
das hat jetzt ne Instanz davon und ich möchte mit der Instanz
12:42
von dem Objekt B nenn ich es mal auch wirklich nur in Objekt
12:46
arbeiten damit also es soll jetzt nicht noch ne andere
12:48
kriegen und hab halt immer nicht den Vorteil da dran gesehen
12:51
warum ich das jetzt von außen reingeben sollte wenn ich es
12:54
doch so schön kapseln kann, darum muss ich mir von außen gar
12:56
keine Gedanken machen, der hat dann einfach sein Objekt b da
12:59
drin. Und das geht halt auch so in die
13:02
Richtung was du meintest mit diesem sich das vorstellen zu
13:05
können. Was ist jetzt das Inverse dabei
13:08
und was bringt mir das Ganze? Ja, also im Endeffekt ist es ja,
13:13
also ich, ich konnte es mir irgendwann so vorstellen,
13:15
zumindest, dass ich mir gesagt hab, OK, es ist nicht so, dass
13:20
das Objekt jetzt sich sozusagen das holt, was es braucht, ne
13:24
also beziehungsweise. Das Objekt in sich selber wie du
13:27
meintest hast du hast nur dort diese Abhängigkeit innerhalb des
13:31
Objektes, das heißt, das Objekt kann sich das einfach holen was
13:34
es braucht, weil es das schon hat, weil es darauf Zugriff hat,
13:37
sondern es bekommt es sozusagen geliefert, also das was es
13:41
braucht bekommt es halt eben geliefert und das ist halt
13:44
sozusagen diese, diese diese das umkehren der Kontrolle.
13:48
Weil das Objekt nicht mehr selber die Kontrolle hat und
13:51
sagen kann, OK, ich weiß, was ich also was ich habe, also zum
13:54
Beispiel der CD Player, sagt Ey, das ist meine CD, nur ich krieg
13:58
die sondern. Es hat halt eben nicht mehr
13:59
diese Kontrolle, sondern muss darauf warten, dass eben etwas
14:03
anderes, nämlich der Mensch, dann am Ende die entsprechende
14:06
CD einlegt, um zu sagen, OK, jetzt kriegst du diese CD.
14:09
Ne, das heißt diese diese Abhängigkeit wird von außen von
14:13
was anderem kontrolliert und nicht von dem Objekt selber und
14:17
das war für mich dann irgendwann so der OK, das meinen die mit
14:20
Kontrolle umdrehen, weil irgendwie dachte ich immer so,
14:22
weil am Ende weißt du ich, ich hab manchmal glaub ich so n
14:25
richtig verquerten. Sachverstand, der sich irgendwie
14:28
Sachen komisch vorstellt. Und ich dachte halt immer so hä,
14:31
das Objekt macht doch trotzdem noch die Sachen, weißt du also
14:34
das Objekt hat doch trotzdem noch die Kontrolle, weil es ja
14:37
trotzdem irgendwie am Ende die entsprechenden Funktionen und so
14:40
aufrufen. Ja, und genau das war halt auch
14:43
das Thema am Anfang bei mir, wo ich mir dann dachte, warum baue
14:47
ich das ganze ne, aber im Prinzip ich lös die
14:50
Abhängigkeiten auf, ja. Hab aber jetzt die Verantwortung
14:54
von draußen und das war immer so.
14:55
Auch mein Klemmer ne so, ja du kriegst das jetzt übergeben.
14:58
OK das Objekt selbst macht sich jetzt keine Gedanken mehr wie
15:00
das Objekt aussieht, was von draußen reinkommt, es verwendet
15:03
das einfach nur, also hab ich diese Abhängigkeit irgendwo
15:05
aufgelöst. Hab ja aber das Problem, dass
15:07
ich jetzt draußen darüber entscheiden muss und da dachte
15:10
ich mir anfangs dann halt immer so ja, aber warum macht es denn
15:12
nicht Sinn das zu Kapseln? Und dann hab ich so ne
15:15
geschlossene Einheit weißt du wo alles safe ist so.
15:20
Ich kann diesen Gedankengang auch heute noch nachvollziehen,
15:23
allerdings gibt es viele Faktoren, die genau dann für
15:25
Dependency Injection sprechen und ich finde was also wenn man
15:28
sich überlegen möchte, was das Ganze bringt, können wir ja mal
15:32
n kleines Beispiel machen um das relativ schnell zu
15:34
verdeutlichen, weil ich glaube wir hatten in der Singleton
15:37
Folge gerade in Bezug auf Testbarkeit drüber gesprochen,
15:42
warum da dependency Injection gut wäre.
15:45
Das wär jetzt so ein Punkt, der ganz klar dafür spricht, halt
15:48
ja. Aber lass uns mal ein Beispiel
15:51
machen. Wir haben ja ganz oft
15:56
essensbeispiele bei uns gehen wir mal so ein bisschen in die
16:02
Richtung, aber da damit es nicht langweilig wird, nicht direkt
16:05
auf die Essensherstellung wie sonst, sondern lass uns mal über
16:08
so eine Art Lieferservice sprechen und stell dir vor, du
16:12
hast so einen Orderservice, worüber du bestellen kannst und
16:18
jetzt möchtest du darüber bestellen und was beinhaltet so
16:23
ne Bestellung? Du hast einerseits n Payment ja,
16:25
also dass du sagst ich möchte das halt auch gleich bezahlen
16:28
wenn ich bestelle also der Kunde möchte das gleich bezahlen und
16:31
ich als Anbieter möchte gewährleisten, dass er das auch
16:34
bezahlen kann und hab natürlich auch sag ich mal ne Art
16:38
Shipping. Ja also beispielsweise.
16:42
Er muss angeben, wo er wohnt. Wohin muss das geliefert werden
16:46
und so weiter wenn es jetzt so um Essensbestellung geht, ja und
16:50
angenommen ja gut, finanziere das angenommen ich implementiere
16:55
das jetzt ohne Dependency Injection, das heißt ich hab
16:59
jetzt n Order Service und wenn ich den Anlege.
17:05
Instanziiert er für sich selbst einen Shipping Service und
17:08
Payment Service und den braucht er ja, er braucht diese beiden
17:11
Services um seine Aufgabe vollenden zu können und da sieht
17:16
man jetzt vielleicht schon oder kann man sich schon denken, so
17:18
okay jetzt entscheidet der Order Service selbst da drüber wie
17:24
bezahlt wird und wie ausgeliefert wird, das muss er
17:28
ja jetzt für sich ohne Wissen von außen festlegen.
17:32
Ja, wenn ich keine Dependency Injection hab, so dann sagt er
17:36
zum Beispiel weiß nicht bezahlen Paypal Guthaben viele vielleicht
17:42
nicht alle, wir machen Kreditkarte, wir machen jetzt
17:45
einfach Kreditkarte, jetzt Visa, ja und das ist jetzt eingestellt
17:49
und Versand ja keine Ahnung essensbestellung wir haben wir
17:56
schicken den mit Fahrrad los so der fährt immer mit Fahrrad.
18:00
So, das ist jetzt so. Unser Shipping Service ist n
18:03
Mitarbeiter auf dem Weg weißt du glaub ich ne ja so heißt das
18:06
glaub ich so heißen die hier ja schön Rucksack hinten drauf, da
18:10
ist die Pizza drin und los geht es so das heißt du hast ne sehr
18:14
sehr enge Kopplung, weil das ist jetzt dein Order Service jetzt
18:18
bestellen die Leute und können nicht wählen wie Sie bezahlen
18:22
wollen wie es geliefert werden soll, die geben jetzt so ihre
18:25
Daten ein ich wohne da und da und bestellen.
18:28
Ja, so, für viele mag das jetzt gut gehen, ne Fahrrad, ja wie
18:31
weit? 5 Straßen weiter kein Thema Fahr
18:33
ich hin jetzt bestellt aber einer der im Nachbarort wohnt
18:37
weißt du und 10 Kilometer bergauf mit dem Fahrrad nervig.
18:42
Da wird das. Abendbrot Schneidig genau so,
18:47
aber du kannst es nicht ändern, weil das ja so eng gekoppelt
18:49
ist. Ja, also der Orderservice hat
18:51
sich jetzt nur mal so aufgebaut. Doof.
18:53
Schwierig. Sehr schwierig und da denk ich
18:57
merkt man schon so. Na, wär schon cool, wenn ich
19:00
vielleicht das von außen so n bisschen reingeben könnte.
19:03
Ja und entscheiden kann mit meinen, mit meiner Außenwelt,
19:07
mit meinen Infos von draußen, was den Service an sich ja nicht
19:10
interessiert, der will eigentlich nur wissen, ich
19:14
möchte also was für n shipment Service hab ich wo ihm das
19:17
vielleicht noch nicht mal richtig wichtig ist.
19:18
Was das für einer ist im besten Falle, sondern er möchte einfach
19:22
n Service haben womit bezahlt werden kann, also nicht shipment
19:25
geliefert werden kann und payment bezahlt werden kann.
19:28
Und von außen möchte er einfach nur vorgegeben oder mitgegeben
19:31
bekommen, was das für einer ist. Weißt du ja ja klar genau, also
19:35
im Endeffekt, du hast ja schon gesagt, du bist ja viel
19:38
flexibler dadurch ne, also du hast ja ne viel viel höhere
19:40
Flexibilität, einfach allein dadurch, weil du ja zum Beispiel
19:43
sagen kannst, Pass auf, ich möchte jetzt, ich hab zum
19:47
Beispiel keine Visa Karte, ich möchte das mit Paypal oder so
19:49
bezahlen, ne oder keine Ahnung, vielleicht geht es auch darum,
19:52
dass du das vielleicht auch der. Der Lieferservice selber zum
19:59
Beispiel gucken kann also nicht, dass du das selbst entscheidest.
20:02
Das ist ja immer die Frage, von wo sozusagen diese Entscheidung
20:04
kommt, was jetzt injected wird, sag ich jetzt mal.
20:07
Aber vielleicht sagt der Lieferservice selber, guck mal
20:09
absurd, so viel Kilometer müssen wir das Auto nehmen und nicht
20:11
mehr das Fahrrad oder keine Ahnung, vielleicht gibt es ja
20:13
verschiedene Lieferservices, beispielsweise die.
20:17
Irgendwie an also die sagen, OK, ich würde das liefern, ne und
20:20
der eine sagt ich brauch 3 Stunden weil die Halt nur
20:23
Fahrräder haben und der andere braucht halt 10 Minuten, weil
20:26
sie halt eben auch Autos haben oder Roller oder frag mich nicht
20:29
ne also wird im Endeffekt einfach flexibel in der Software
20:32
gesagt OK pass auf wir wir können das, wir können wir wir
20:35
haben überhaupt diese Möglichkeit die diese Auswahl
20:40
oder dieses dieses Dynamische ja auswählen von Zahlungen und
20:46
Lieferungen ne. Und du bist natürlich auch super
20:49
gut dabei, dass du auch alles natürlich deutlich einfacher
20:54
erweitern kannst. Am Ende ne, weil also nicht nur
20:58
die Flexibilität, sondern auch die Erweiterung deiner Software.
21:01
Wenn du sagst okay du möchtest jetzt zum Beispiel noch einen
21:03
neuen Zahlservice beispielsweise einführen, weil du sagst ja,
21:06
paypal, Visa ist irgendwie blöd, vielleicht noch mastercard oder
21:09
keine, ich weiß gar nicht, was es da noch alles gibt.
21:12
Aber dass du halt irgendwie noch ne mögliche oder klarer hast.
21:14
Du glaub ich auch sowas. Ne was irgendwie.
21:16
Ja, das ist so n Ding. Heutzutage, das ist so n Ding.
21:18
Klarer ist so n Ding. Kannst du eigentlich essen, auch
21:21
auf Raten bezahlen? Ich weiß es nicht.
21:24
Du. Kriegst aber auch nur so n
21:25
Sechstel geliefert. Ja einmal 30€ oder jeden Tag im
21:29
Monat einen Euro genau, aber das war halt ein Stück Pizza genau
21:34
und da kannst du halt einfach relativ schnell eben deine
21:37
Software erweitern, weil du halt noch NN weiteren
21:38
Zahlungsanbieter hast, den Du dann auswählen kannst, den du
21:42
dann im Endeffekt nutzen kannst. Und der Orderservice will ja
21:45
nicht nichts anderes wissen als zu sagen, OK, wie du schon
21:48
meintest, du brauchst irgendwie n Payment Service.
21:50
Der irgendwie Pay machen kann, also der will ja nichts wissen,
21:54
der also das ist ja auch wieder diese Umkehr, diese Inversion of
21:57
Control, ne, also der der Order Service sagt jetzt ey, ich muss
22:02
irgendwie sagen bezahl ne und das geb ich aber jetzt
22:06
beispielsweise eben an den Payment Service ab und der
22:10
Payment Service, egal was das ist, ob jetzt gerade am Ende da
22:14
n Claner drunter liegt oder Paypal oder Visa ist mir völlig
22:18
egal. Aber du machst das.
22:20
Payment Service du zahlst das Ding so nach dem Motto.
22:24
Ja, aber im Prinzip lass uns mal noch ein Gedankenbeispiel
22:29
weitergehen. Ich gebe dir mal so ein kleines
22:30
Szenario, ja, weil wir ja gesagt haben, Testbarkeit und jetzt
22:37
möchte ich eine Funktion haben, also das ist jetzt so deine
22:41
Anforderung, die ich dir jetzt gebe, ne, dass quasi.
22:45
Im Order Service ermittelt wird. Wenn ich bestellt habe, wie
22:49
lange ungefähr die Lieferzeit ist.
22:53
So und das möchtest du jetzt abtesten was für Probleme das
22:57
geht ja jetzt in die gleiche Richtung was wir gerade
22:58
besprochen haben, aber um mal das an einem klaren Feature ja
23:01
auch mal zu geben, was ist jetzt der bessere Weg wenn ich es
23:05
testen möchte also ja Spoilerwarnung das mit
23:08
Dependency Injection zu machen aber wieso?
23:11
Weil wer auf welche Probleme treff ich denn wenn ich das
23:14
nicht mache? Na also ich geh erst mal weiter
23:19
mit deinem, mit deinem, mit deinem Lieferzeit.
23:22
Weil also das erste was mir einfallen würde wäre, dass du ja
23:25
auf jeden Fall in deinem Test nicht tatsächlich einen
23:27
Lieferservice ansprechen möchtest.
23:28
Nee, du möchtest nicht tatsächlich bezahlen und du
23:30
möchtest auch nicht tatsächlich jetzt etwas verschiffen.
23:33
Ne, deswegen möchtest du nicht diese Services nehmen, sondern
23:36
du kannst es halt zum Beispiel Mocken und einfach zum Beispiel
23:38
sagen, ja OK, ich nehme jetzt aber meintest Payment Service
23:41
und mein Testlieferservice so als Beispiel ne das wäre ja ne
23:45
Möglichkeit, aber du hattest jetzt zum Beispiel noch
23:48
angesprochen lieferzeitraum oder sowas.
23:52
Ne Lieferzeit, weil das ist ja genau der Punkt.
23:55
Ne wenn ich jetzt verschiedene shipment services hab ne und ich
23:58
möchte zum Beispiel wissen wie lange dauert das?
24:01
Wenn er mit Fahrrad fährt, mit dem Roller oder mit dem Auto
24:03
oder zum Beispiel das abhängig machen von der Entfernung.
24:06
Wer bestellt hat, dann will ich ja so ne Szenarien testen und
24:09
aufbauen können und da bist du ja gerade schon genau in die
24:12
richtige Richtung gegangen. Warum das mit Dependency
24:15
Injection einfach viel besser funktioniert.
24:18
Ja, ja, also es ist ja beispielsweise, wenn du jetzt
24:21
zum Beispiel wirklich sagst, ey, ich möchte jetzt.
24:25
Verifizieren, dass ab der und der Kilometerlänge
24:28
beispielsweise auch wirklich n Auto genutzt wird.
24:30
Dann kannst du das ja wie ich halt eben auch schon n bisschen
24:33
so meinte. Du kannst es mocken, du kannst
24:34
ja sagen OK pass auf, du gibst jetzt zum Beispiel vor, das sind
24:39
die Bedingungen ne und anhand dieser Bedingung teste ich
24:43
jetzt, dass dass halt eben zum Beispiel auch wirklich das Auto
24:45
verwendet wird und dafür, dass du es aber auch so machen kannst
24:48
und das so vorgeben kannst. Mogst du halt deine
24:50
entsprechende, sag ich mal deine entsprechenden Kriterien
24:54
innerhalb der Services, die halt diese Dependencies beinhalten.
24:57
Ne, also alles was Abhängigkeiten sind kannst du
25:01
sozusagen einfach faken, ne, also du kannst halt einfach
25:05
vorgeben was da passieren soll, ohne dass du halt am Ende
25:08
wirklich das nutzt, was wirklich, ich sag mal in echt
25:12
irgendwie passiert. Das heißt du kannst es halt
25:14
explizit auf deine sag ich mal Testfälle auch anpassen.
25:18
Das, was du für mich testen willst.
25:19
Und das ist halt n Riesen riesen Benefit und das können ja auch
25:24
mogs, also können ja auch sehr stumpf sein ne?
25:28
Also ich kann ja jetzt zum Beispiel auch nen Shipment
25:31
Service implementieren, der einfach dann sagt ja wie lange
25:34
brauchst du 10 Minuten ja immer 10 Minuten, aber das ist ja
25:38
egal, weil ich gebe diese Abhängigkeit ja rein.
25:41
In mein Order Service und dann kriegt er halt immer 10 Minuten
25:45
angegeben, aber das ist ja genau das, was ich jetzt gerade
25:48
vielleicht in meinem Testfall verwenden möchte.
25:50
Ja, dass du halt sowas sagst wie ich möchte, gewisse
25:54
Funktionalitäten im Order Service testen, wenn der
25:57
Shipment Service sagt ich brauch 10 Minuten oder bei meinem
26:01
Payment Service ist mir im Test vielleicht egal wer das jetzt
26:05
bezahlt, ich möchte einfach nur von außen vorgehen können ob es
26:08
bezahlt wurde oder zum Beispiel n Transaktionsfehler war so.
26:11
Solche Geschichten, und das kann ich ja alles von außen
26:14
reingeben, und das ist mein riesen riesen Vorteil in Sachen
26:17
Testbarkeit. Ja, auf jeden Fall.
26:20
Also das Testbarkeit sowieso. Es ist n Riesenthema, ich weiß,
26:26
das klingt manchmal so n bisschen so, als würden wir
26:28
irgendwie das ganze. Haben wir so ne Tester Sekte,
26:33
aber es ist halt wirklich sehr sehr wichtig, dass man sich halt
26:36
eben dann auch auf den Code verlassen kann und dazu zählt
26:39
halt eben, dass man eben seinen Code auch richtig testet und da
26:42
ist es halt wieder wichtig, dass der Code auch testbar ist und
26:44
das geht halt zum Beispiel zumindest aus unserer Erfahrung
26:48
auch immer sehr gut, zum Beispiel mit Dependency
26:50
Injection. Also das ist NNN sehr sehr
26:53
großer Vorteil, ansonsten hast du natürlich auch noch, weil wir
26:57
ja gerade noch n bisschen bei Vorteilen sind, auch zum
27:00
Beispiel die. Die Lesbarkeit also du hast halt
27:03
klar, du siehst halt relativ klar und nachvollziehbar wo die
27:10
Abhängigkeiten. Ich sag jetzt in
27:11
Anführungsstrichen mal fließen, weißt du?
27:13
Ja. Und das hatten wir vorhin auch
27:15
schon n bisschen angesprochen und da hatten wir auch schon mal
27:18
ne Folge drüber gemacht. Über die Solid Prinzipien und
27:20
gerade dieses Single Responsibility Principal, was
27:23
wir auch besprochen hatten, also die Beziehung lieber hör da
27:27
gerne mal rein, wenn dich das interessiert und du sagst Ey
27:28
solid ey, das klingt cool, wollte ich schon immer mal was
27:31
drüber hören, da haben wir ne Folge drüber gemacht, aber genau
27:33
diese Single Responsibility, die hast du ja dadurch gegeben, weil
27:38
du ja zum Beispiel sagst OK du hast n Order Service der sagt OK
27:40
ich nehme zum Beispiel diese entsprechende Order entgegen.
27:43
Ne und berechne vielleicht wieviel bezahlt werden muss und
27:47
wohin es geliefert werden muss, aber die tatsächliche Ausführung
27:51
des Zahlens, das wird halt woanders hingegeben.
27:54
Ne an den Payment Service und die tatsächliche Lieferung des
27:58
Ganzen wird halt dann wieder n shipment Service gegeben und das
28:01
ist halt genau diese Verantwortlichkeit die da im
28:05
Endeffekt auch getrennt wird, was am Ende natürlich auch ne
28:07
gute Architektur der Software zugrunde hat, ne oder dann?
28:12
Als Grundstein sozusagen. Ich finde halt den Punkt auch
28:17
wirklich wichtig, Lesbarkeit zu sagen.
28:19
Ich sehe, welche Klassen verwendet werden von anderen
28:24
Klassen, indem ich zum Beispiel im Konstruktor ja schon nehmen,
28:28
also wir kommen gleich auf die Form der Dependence Injection,
28:30
aber gehen wir jetzt mal vom Konstruktor aus, dass ich eine
28:33
Constructor injection mache und den Service über den Konstruktor
28:38
in meinen Service reingebe ja. Und dadurch sehe ich halt auch
28:42
gleich schon von der Architektur her, welche Abhängigkeiten da
28:45
sind, weil ich möchte noch mal ganz kurz auf das Singletonpad
28:48
dann eingehen, weswegen hier überhaupt diese Folge jetzt da
28:51
ist. Ja, weil wir, da hatten wir ja
28:52
gesagt, du hast irgendwann keinen Überblick mehr, wer
28:55
verwendet jetzt diese Singleton Instanz und manipuliert sie
28:59
vielleicht ja oder ruft da Funktionen auf und du weißt
29:01
einfach gar nicht mehr, wo sie überall in deiner Software ist,
29:04
weil sie so global am Ende ist. Und das ist der Vorteil an
29:07
Dependency Injection. Wenn ich jetzt sage, ich möchte
29:10
es nicht als Single umsetzen, sondern ich habe eine Klasse,
29:13
die ich sehr viel brauche überall, dann kann ich sie aber
29:17
genauso da, wo ich sie brauche, via dependency Injection halt
29:23
mit Reingeben und seh aber dann auch, dass sie da verwendet
29:27
wird. Und das ist halt auch n Prinzip,
29:29
was ja auch viele Frameworks verwenden, zum Beispiel wenn
29:33
Leute mit Angular arbeiten. Die Services werden ja auch
29:36
injiziert in deine Components beispielsweise, und das ist auch
29:41
ne ne sehr coole Art und Weise damit zu arbeiten am Ende, um
29:46
zum Beispiel auf gleichen Instanzen zu arbeiten.
29:48
Wir hatten jetzt zum Beispiel gesagt, N Logger Service, so
29:50
beispielsweise wär jetzt so n so n klassisches Beispiel, dann
29:54
möchte ich natürlich. Eine Instanz eines Loggers haben
29:57
und wenn ich irgendwo n log aufrufe, dann möchte ich zum
30:00
Beispiel, dass es auch wirklich im gleichen Logfile landet oder
30:02
in der gleichen Ausgabe allgemein, aber das kann ich
30:06
dann halt mit dependency Injection lösen und hab halt
30:09
auch im Test dann die Möglichkeit von außen
30:11
vorzugehen, wie dieser Loggerservice aussieht.
30:14
Ne und das ist n Riesenvorteil dabei.
30:17
Im Umkehrschluss wär es n Single nur und der wär einfach überall
30:20
fest integriert. Da hab ich in meinen Tests auf
30:22
einmal irgendwelche logs wo ich mir denke hä mal so weißt du so
30:27
als Side? Effects mal.
30:28
Na ja, das kommt dann so flaky Tests unter Umständen gerade bei
30:32
Singletons hatten wir auch besprochen, das kann man
30:35
natürlich super vermeiden dann durch Dependency Injection, du
30:38
hattest ja gerade zum Beispiel angesprochen Constructor
30:41
injection ne, also das ist auch glaub ich das was.
30:45
Irgendwie super häufig vorkommt. Also eigentlich, ich würde
30:49
sagen, wenn man die Penancy Injection benutzt, kenn ich das
30:52
eigentlich hauptsächlich so, dass es über Constructor
30:54
Injection passiert. Du hattest das ja schon mal n
30:58
bisschen angesprochen, eben gerade Constructor Injection,
31:01
die Abhängigkeiten werden über den konstruktor Halt injiziert,
31:05
ne, also es klingt halt immer so.
31:07
Wie gesagt, ich ich meinte wär vorhin schon das klingt so
31:10
hochtrabend manchmal, Injection ist ja nichts anderes, als dass
31:13
du n Parameter übergibst, dass du einfach sagst.
31:15
Du erzeugst jetzt zum Beispiel diesen Order Service, den wir
31:18
hatten und dann gibst du in den Konstruktor den Payment Service
31:21
mit rein, als Parameter Übergabe sozusagen ne in den Konstanz
31:25
davor, genau genau und halt den Shipping Service genauso ne und
31:29
dann hast du die halt und musst die dann halt eben so wie man es
31:34
halt kennt über den Konstruktor in das Objekt reingeben ne so,
31:37
aber das ist ja beispielsweise halt eine Sache die man jetzt
31:40
gibt ja noch andere Formen hast du noch ne andere?
31:44
Was es halt auch gibt ist so Setter Injection, also so auch
31:50
klassisch über eine Set Funktion macht das Ganze natürlich noch
31:57
ein Stück weit flexibler, weil es nicht an den Konstruktor
32:00
gebunden ist. Das heißt ich kann diesen
32:03
Service Instanziieren ohne diese Abhängigkeit reinzugeben und
32:09
kann zur. Also irgendwie an einer anderen
32:11
Stelle zur Laufzeit. Zum Beispiel dann das Setten,
32:15
also dann wirklich setzen. Diese Abhängigkeit, das klingt n
32:19
Stück weit flexibler, ist es irgendwo auch, aber ich finde
32:22
mir ist das manchmal nicht so explizit genug, wenn ich so
32:25
drüber nachdenke, weil ich halt mich vielleicht zu sehr
32:29
entkoppel davon, ich weiß nicht, wie es anders sagen soll, aber.
32:32
Was ist, wenn du diesen Setter nie aufrufst oder vergisst, ihn
32:35
aufzuhören? Richtig so, ja, das ist oder
32:37
oder rufst ihn einfach aus Versehen noch mal irgendwann auf
32:40
und überschreibst dir wieder Sachen, weil du halt wie gesagt
32:43
diese Instanz neu setzt da drin, das find ich, ist halt auch
32:46
immer so n bisschen schwierig, aber hat also wenn du diese
32:51
Flexibilität brauchst ist es auf jeden Fall n valider
32:53
Anwendungsfall das so zu machen. Ja, also ich glaub es gibt es,
32:57
weil man das vielleicht wirklich irgendwie verwenden kann.
32:59
Ich hab das glaub ich selbst noch nie verwendet.
33:01
Ich find es halt auch genau aus den Gründen, die du gerade
33:04
genannt hast, finde ich es schwierig, weil du kannst ja
33:07
irgendwie gar nicht gewährleisten, ob dann zum
33:10
Beispiel dieser Setter, also ob ob das wirklich gesetzt ist, was
33:14
du setzen sollst. Oder du musst vielleicht
33:17
irgendwie wieder ne Behandlung dahinter irgendwie machen, wenn
33:20
du sagst, ja, das gibt es aber gar nicht, weil du halt die
33:22
Dependency eben nicht injected hast.
33:24
Ne, das ist wahrscheinlich sehr. Anwendungsspezifisch, dass man
33:30
bestimmt sagt. Ja, wenn du, ich glaube halt.
33:33
Wenn du es also ich will, sagen wir mal so ne Art lazy load ja,
33:36
also wenn du quasi zum Erstellen deines eigentlichen Service noch
33:42
nicht die Abhängigkeit definieren kannst oder so und
33:44
das irgendwie nachgelagert kommt.
33:46
Aus Gründen einfach aus Gründen deiner Software.
33:50
OK, dann ist das ne ne ne architekturentscheidung die
33:53
vertretbar ist. Aber wenn ich es eigentlich
33:56
schon zum Erstellen des Service weiß, würd ich es halt auch n
33:58
Konstruktor hauen, ehrlich gesagt.
34:00
Ja, dann gibt es ja glaub ich noch ne dritte Sache.
34:03
Das ist diese Interface Injection, da bin ich ganz
34:06
ehrlich, das hab ich auch noch nie genutzt so eine Interface
34:10
injection ich weiß nicht wie es wie es dir geht, ob du das schon
34:13
mal verwendet hast oder nicht. Also nee, ich.
34:18
Bin ja meins. Es wird auch relativ wenig
34:20
verwendet, aber keine Ahnung hab ich.
34:25
Also das ist halt noch mal noch mal n Schritt weiter ne, also
34:29
dass du sagst ich gebe jetzt keine Instanz einer festen
34:34
Klasse rein. Ja und hab so meine Dependency
34:38
Injection, sondern ich verwende jetzt noch Interfaces dafür, so
34:41
versteh ich das Prinzip dahinter.
34:44
Das heißt, ich implementiere meine Klasse.
34:47
Also nein, meine Klasse implementiert ein Interface, was
34:51
zum Beispiel sagt Inject, also ich hab ne Funktion inject und
34:54
da muss ich einen gewissen Typ reingeben.
34:58
Ja. Ja, in diese Funktion, um so
35:02
dann quasi bereitzustellen, wenn ich das als klasse
35:05
implementiere, dass es eine inject Methode von außen gibt,
35:08
wo ich meine Abhängigkeit dann mitgeben kann.
35:12
Aber was ich dabei wieder schwierig finde, ich mein gut,
35:14
das hast du immer. Am Ende ist es ne Coding Frage
35:16
ne aber mein erster Gedanke war ja dann sag ich ich implementier
35:20
inject und mach da einfach gar nichts drin sowas dann hab ich
35:24
da nämlich überhaupt nichts injiziert am Ende andererseits
35:27
kannst du natürlich sagen ich kann auch n Parameter n
35:29
Konstruktor reingehen und dich ignorieren ja also weißt du es
35:32
denn halt wirklich dass ja weißt du was mir gerade einfällt, ich
35:35
hab das doch schon mal verwendet, das ist jetzt gerade
35:37
in dem Moment fällt mir das ein, weil was auf der das
35:39
Anwendungsbeispiel war. Du hast n Repository, ne, also
35:44
das ist jetzt wirklich codebase, also codetechnisch ne, also n
35:46
Repository ist ja zum Beispiel sozusagen der die Schnittstelle
35:50
die zur Datenbank geht ne und wenn du jetzt sagst du hast
35:53
diese Schnittstelle in deiner Software die zur Datenbank geht,
35:55
ne dein Repository also wir hatten das zum Beispiel
35:58
Repository genannt und du willst es testen, ne, dann kannst du ja
36:02
rein theoretisch sagen ja OK, ich hab aber jetzt in meinen
36:04
Tests zum Beispiel nicht meine echte Datenbank, also haben wir
36:08
sozusagen immer in unserem produktiven Code.
36:11
N Interface von dem entsprechenden Repository zum
36:15
Beispiel, sagen wir mal in also User Repository Interface, nenn
36:19
ich das jetzt mal ne haben wir immer injected und in
36:23
Produktivcode wurde sozusagen immer, also wurde die Instanz
36:26
Injected des richtigen User Repositories weißt du was dann
36:31
im Endeffekt dieses User Repository Interface
36:34
implementiert? Und dann gab es noch n Test User
36:37
Repository, was eben auch dieses User Repository Interface
36:41
implementiert hat und dann konntest du halt.
36:43
Fällt mir jetzt gerade ein rein theoretisch relativ easy sagen
36:47
OK pass auf, du kannst in deiner produktiven Anwendung ne, also
36:50
so wie es halt wie der Code halt wirklich läuft hattest du
36:53
wirklich die zu den Zugriff auf die Datenbank über das echte
36:56
Repository in Anführungsstrichen?
36:58
Und im Test war es dann aber so, dass man eigentlich nur gegen so
37:01
n gewissen Fake gegangen ist. Ne den man dann injected.
37:03
Hat an der Stelle aber den Anwendungsfall kenn ich auch und
37:06
der ist auch richtig gut das so zu machen.
37:09
Aber ich. Wenn ich sowas verwendet hab,
37:11
hab ich es aber nicht so in diesem klassischen Interface
37:13
Injection Prinzip umgesetzt, dass ich halt quasi in meiner
37:16
Klasse ein Interface implementiere mit einer inject
37:19
Methode, sondern ich hab halt gesagt, es gibt so Interfaces
37:23
die Abhängigkeiten darstellen, aber ich kann sagen wie dieses
37:25
Interface aussieht von außen oder wie ich es implementiere
37:30
deswegen. Also ich weiß nicht, also wenn
37:32
das darunter zählt, ja dann hab ich es so auch verwendet, aber
37:36
so nach der Recherche wieso dieses klassische?
37:39
Aber da dieses klassische Interface Injection aussieht,
37:42
muss ich sagen, so hab ich es. So lieb gemacht.
37:45
Also Liebe zu, lieber Zuhörer, wenn du Interface Injection
37:48
schon mal verwendet hast oder sagst, ja, das ist so.
37:51
Richtig lehrbuchhaft. Dann sag es uns.
37:53
Dann schreib uns das auf jeden Fall, aber ich würd sagen,
37:58
genau, also es gibt auf jeden Fall verschiedene Möglichkeiten
38:00
diese Dependence Injection am Ende wirklich umzusetzen und.
38:05
Ich würde sagen, wir können ja noch mal irgendwie gucken, dass
38:07
wir so ein paar Tipps und Best Practices vielleicht so
38:10
mitnehmen, die man vielleicht noch mal dann so zum Abschluss
38:15
so was auf dem Weg mitgeben kann.
38:19
Ja, ich fange mal an, es ist naheliegend, aber wir möchten es
38:24
trotzdem anmerken, denke ich. Dependency Injection ist eine
38:28
sehr, sehr gute Sache. Aber auch bitte hier Vorsicht,
38:33
wenn ich anfange, alles darüber zu machen, nur so als Reminder,
38:37
wie ich damals im Studium mich verhalten hab, wenn ich
38:39
irgendwie was Neues gelernt hatte oder neues Pattern
38:41
kennengelernt hab, dann hab ich es einfach überall erstmal
38:43
verwendet. Also ja kann man machen, aber
38:46
auch Dependency Injection hat seine Grenzen wenn ich jetzt zum
38:50
Beispiel merke ich hab ne klasse und ich muss da irgendwie 56
38:53
Instanzen von Klassen injizieren um die zu verwenden.
38:57
Und mir denke, na ja, ist ja dependency Injection, kann ja
38:59
von außen alles vorgeben, ja und nein, weil das schon wieder n
39:04
Anzeichen ist, dass es denn doch an der Architektur, an der ein
39:07
oder anderen Stelle klemmt, zumindest aus unserer Sicht.
39:10
Wir lassen uns da auch gerne belehren oder korrigieren, wie
39:14
sagt man, weil das zeigt, dass es schon wieder unnötig
39:19
kompliziert wird, dass man einfach denn zu viel
39:21
Abhängigkeiten hat und da mal refectern sollte.
39:24
Ja, also klar ist zum Beispiel, wenn wir über Single über Single
39:28
Responsibility gesprochen haben, könnte es vielleicht sein, dass
39:31
dieser Service oder diese klasse oder ne wo halt eben 567
39:37
Injections stattgefunden haben. Vielleicht macht diese Klasse
39:40
dann doch zu viel, man weiß es nicht, es könnte sein.
39:44
Und es ist n valider Anwendungsfall, weil ich hatte
39:47
ja Angular erwähnt und da haben wir auch selbst die Erfahrung
39:50
gemacht, dass du an den Punkt kommst, wo du auf einmal so 56
39:53
Angular Services drin hast und dir denkst.
39:56
Weiß nicht, ich glaub das artet gerade n bisschen aus.
40:00
Lass mal refact. Dann so ne.
40:02
Na du kommst halt schnell dahin, dass du sagst, du brauchst den
40:04
Service noch. OK, ja dann komm injected den
40:07
Service, das ist genau wie bei Single ne, weil du hast halt
40:11
diesen Punkt wo es sehr easy ist den dann reingeben zu können, ne
40:14
gerade gerade. Mit Frameworks wie Angula, wenn
40:18
du den einfach in Konstruktor schreibst sozusagen.
40:21
Das Beste ist ja, wenn du irgendwann n Service hast.
40:24
Ja, also sagen wir mal Service 1.
40:25
Der Injected Service 2 und 3 und Service 2 Injected aber auch
40:31
noch mal Service 3. Also weißt du also du hast dann
40:34
du hast dann quasi wo du dir denkst OK muss jetzt bis auf
40:37
Service 3 selber also bis auf deinen Service der überall
40:40
injected und muss der überall injected werden also.
40:43
Ne, da kann man sich dann vielleicht noch mal überlegen.
40:46
OK, hab ich hier nicht vielleicht n bisschen
40:48
übertrieben? Das ist nämlich auch wieder so n
40:50
Ding zirkuläre Abhängigkeiten gerade können halt auftreten,
40:55
gerade wenn du wirklich exorbitant viel dependency
40:58
Injection machst und vielleicht irgendwann den Überblick
41:00
verlierst und nicht mehr weißt wo gehen denn die die Penancies
41:03
hin, weil wenn du jetzt zum Beispiel sagst ne, also das ist
41:06
relativ. Schnell erklärt ne zirkuläre
41:09
Abhängigkeit ist wenn du sagst du kannst Service A nur mit
41:11
Service B nutzen und Service B nur mit Service A nutzen.
41:15
So wenn du jetzt aber sagst OK das ist Henne ei Problem, was
41:18
kannst du jetzt nutzen ohne das andere ne also es wird halt so
41:21
nicht funktionieren. Und wer jetzt sagt, das klingt
41:24
abwegig, nein, sowas kann sehr schnell passieren.
41:28
Klar, nicht. Nicht in konstruierten
41:30
Beispielen. Das wird wahrscheinlich nicht so
41:31
einfach sein, aber. Ja, es ist halt.
41:34
Es ist leider möglich. Genau.
41:36
Also man kann sagen, dass es halt auch klare Regeln geben
41:39
sollte, ne, dass man da einfach auch wirklich n Überblick
41:41
behält, definitiv. Gerade auch wenn wir jetzt zum
41:43
Beispiel über das gesprochen haben, wenn man zum Beispiel
41:45
sagt, OK, du kannst vielleicht irgendwie ne Constructor
41:47
injection oder ne Setter Injection machen und man dann
41:50
vielleicht sagt, EY ne, also sagen wir mal, du hast irgendwie
41:53
n Team. Der die eine Person aus dem Team
41:56
sagt sich OK, ich mach aber jetzt immer Constructor
41:59
Injection, die andere macht immer Setter Injection.
42:00
Am Ende braucht man aber das ein oder das andere vielleicht gar
42:03
nicht zwingend, weil das vielleicht zum Beispiel die
42:05
Setter Injection vielleicht auch mit der Constructor Injection zu
42:08
lösen wäre, dann sollte man sich vielleicht auch auf ne
42:11
Einheitlichkeit einigen um halt auch eben auch diese diesen ich
42:15
sag mal diese diese das was wir vorhin als Vorteil angesprochen
42:19
haben, dass man halt ne. Übersichtlichkeit schafft von
42:23
den Dependencies her. Wenn du aber dann zum Beispiel
42:26
immer wieder dies und das und jenes verwendest, verschiedene
42:28
Möglichkeiten, wenn es sein muss, klare Sache, aber wenn es
42:32
nicht unbedingt sein muss, dann vielleicht so eine
42:34
Einheitlichkeit haben, damit man auch sich darauf verlassen kann,
42:37
dass da, wo man hinguckt, auch, dass man da halt eben auch denn
42:39
die Dependencies eben erspähen kann, sozusagen.
42:43
Ja, ist ein sehr guter Punkt und wo wir auch bei Interfaces sind.
42:49
Wenn man im Test oder beim Testen merkt, OK, ich habe zwar
42:52
den Vorteil von Dependency Injection und kann jetzt von
42:55
außen alles implementieren und vorgeben, ich kann zum Beispiel
42:58
die Interfaces implementieren, die du gerade genannt hattest.
43:00
Ja, wenn ich aber merke, es ist unfassbar aufwendig, irgendwas
43:06
zu instanziieren, weil ich halt erstmal 56 Klassen vorher
43:10
implementieren muss, ja, weil du alles so ineinander, die
43:14
Injektest sozusagen. Auch schwierig.
43:17
Und dann wird es auch unübersichtlich.
43:19
Also das ist dann auch so ein Warnzeichen, einfach.
43:22
Ja, auf jeden Fall. Also angenommen du hast Service
43:27
A brauch Service B also möchtest du Service B Reingeben aber um
43:30
Service B Instanziieren zu können brauchst du Service C und
43:34
so weiter dann hast du halt eine Riesenkette an Code um überhaupt
43:37
erstmal alle Objekte zu instanziieren und dann merkst du
43:40
halt auch irgendwann so. Vielleicht habe ich es.
43:42
Übertrieben? Ich habe es völlig übertrieben.
43:47
Ja, aber zum Beispiel das was, was ich vorhin meinte.
43:50
Es ist, wenn wenn du quasi n sagst OK ich ich injekte nicht
43:54
einfach nur ne Klasse, sondern ich injekte zum Beispiel also
43:56
sagen, wenn wir bei Payment sind ne es ist natürlich nicht
43:59
schlecht zu sagen OK du hast n du indizierst nicht einfach nur
44:02
n Payment Service und dieser Payment Service sagt
44:04
beispielsweise OK pay with Paypal pay with ne Visa oder was
44:10
auch immer, sondern du sagst dann am Ende wirklich irgendwie,
44:13
dass du n Interface reingibst und sagst ne, das ist NI payment
44:18
Service beispielsweise und dann kannst du halt zum
44:22
entsprechenden Zeitpunkt halt auch oder wie du auch meintest,
44:25
vielleicht auch zur Laufzeit, sogar je nachdem wann du das
44:27
Objekt konstruierst eine entsprechende Injection mit
44:31
Reingeben oder eine entsprechende Dependency
44:33
Injection so. Rum, ja.
44:35
Genau. Und dann kannst du halt eben aus
44:38
diesen Interfaces verschiedene, ja ich sag mal.
44:44
Implementierungen mitgeben so ne oder jetzt zum Beispiel auch das
44:48
Beispiel, was ich vorhin meinte mit dem mit dem, mit dem Testen,
44:51
dass du dann zum Beispiel auch ein ein Interface faken kannst
44:55
oder ein Implementierung des Interfaces für das Repository.
44:57
Fake kannst so ja, ja, das kann zum Beispiel auch helfen, ja,
45:00
ich. Würde sagen, dann haben wir das
45:03
Thema eigentlich auch wirklich gut besprochen.
45:05
Wir sind auch wieder fortgeschritten in einer Zeit
45:07
auch so ein Standardsatz, weil wir immer mit ein bisschen
45:09
verquatschen. Wir sollten aber mal im Vorfeld
45:12
immer Wetten abschließen, wie lange die Folge dauert.
45:16
Ja, ich glaub, das kriegen wir, das werden wir nie treffen, aber
45:19
trotzdem die Anmerkung, Liebe zuhören, Liebe zuhören.
45:21
Falls du noch fragen zu dem Thema hast, Anmerkung oder Dir
45:25
sagst so hey wär cool wenn ihr auch mal Beispiele gebt, so als
45:28
Code, dass wir da irgendwie mal Content zu machen, lass es uns
45:31
gerne wissen. Auf jeden Fall.
45:33
Und ansonsten, wie gesagt also die Links dann auch dazu ne,
45:36
also du kannst uns schreiben auf einem Plattformen, da gibt es
45:38
die Links natürlich wie gehabt in den Shownotes guckst du
45:41
einfach mal rein und wenn du jetzt zum Beispiel auch ein
45:44
Thema hast, wie zum Beispiel dieses Thema, das war ja auch
45:45
ein Wunsch, ne, dann schreib uns auch gerne auf der Plattform
45:50
deiner Wahl. Ganz genau.
45:54
Ja, was was haben wir noch? Wichtig ist natürlich immer, und
45:57
das müssen wir sagen, ja, wir kommen nicht drum herum, Regie
46:01
sagt, Wir müssen das Sagen und. Wenn dir der Podcast gefällt,
46:06
dann nimmt viel ihn auf jeden Fall weiter und lass ne
46:08
Bewertung da. Und und das ist natürlich
46:10
wichtig, die haben wir ja jetzt gar nicht vor allzu langer Zeit
46:13
mitgekriegt. Lass mal n Abo da und Aktivier
46:15
das Glöckchen, weil dann verpasst du keine neue Folge,
46:18
das ist ganz ganz wichtig, Oh Yes, ansonsten Tino, vielen Dank
46:23
für das tolle Gespräch über gar nicht die Penancy Injection, ich
46:26
hätt nicht gedacht, dass wir so lange darüber reden können, aber
46:28
wir haben es geschafft ansonsten.
46:30
Ist n geiles Thema. Ist es auch.
46:33
Ansonsten wünsche ich dir Tino und auch dir Liebe zu lieber
46:36
zuhören, einen tollen Tag, ne tolle Zeit bis zur nächsten
46:39
Folge deine Codingbuddy gemeinsam besser.