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