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.