Wie oft hast du schon Code geschrieben?
Der ist schwer zu ändern, schwer zu erweitern oder zu testen war,
weil er von anderen Objekten abhängig war.
Wie oft hast du dir gewünscht, dass deine Objekte einfach
auszutauschen und zu konfigurieren sind, ohne deinen
ganzen Code zu ändern? Wenn du diese Fragen mit ja
beantwortet hast, dann ist diese Folge etwas für dich.
Und damit herzlich willkommen zu Folge 75 des to Dive Loper
Podcasts heiratet Manuel, wie gehts dir?
Dreimal so Grüß dich haben wir schon wieder eine technische
Herausforderungen nochmal, da schneiden wir alles raus, kriegt
davon nichts mit und ihr habt uns n bisschen früher, weil sie
hier vor dem Mikrofon. Ja, die Stimmung ist gut, trotz
trübem Herbstwetter, weil wir zum einen wieder ein.
Wunsch eines Hörers aufgreifen können wir wieder über ein
technisches Thema zu sprechen. Wir tauschen uns heute über die
Pence Injection aus und zum anderen freuen wir uns darüber,
dass auch wieder Kaffee Einladung eingetrudelt sind und
zwar haben wir 2 Kaffee von Julia und 5 Kaffee von Daniel
bekommen, an dieser Stelle herzlichen Dank dafür.
Bevor wir ins Thema einsteigen, vielleicht ein kleiner Rückblick
beziehungsweise ein Ver Feedback was wir von euch bekommen haben.
Wir haben eine Mail bekommen von Claudia.
Ja, wir haben ganz viele Mails bekommen.
Tatsächlich, wir haben ja letzte Folge über unseren Werdegang
gesprochen und ein bisschen erzählt, sowas malte und ich für
Stationen auf unserem Lebenslauf schon durchlebt haben und da kam
super viel Reaktionen darauf und wir haben auch ganz viele Mails
bekommen von Leuten, die ganz verschiedenste Werdegänge
irgendwie durchlebt haben und jetzt trotzdem alle irgendwie
gemeinsam in der IT mit uns hier arbeiten und leben und das hat
uns sehr gefreut, dass wir auch so viele persönliche Geschichten
von euch. Zu hören bekommen durften.
Und der eine hat uns ganz besonders berührt, die kam von
Claudia, die wirklich einen sehr ungewöhnlichen Werdegang
gegangen ist und jetzt aber auch als Zuhörerinnen und
softwareentwicklerinnen. Und mit uns unterwegs ist auf
dieser Reise und der Geschichte würde ich gerne einmal kurz
vorlesen. Wir haben ein bisschen mehr
hingeschrieben, ob das in Ordnung ist.
Und Claudia hat etwa eine hat geschrieben, dass sie etwas
komplizierte Laufbahn hat, sie es genannt, hingelegt hat.
Also sie wusste lange nicht, was sie werden wollte, hat dann in
der 12. Klasse im zweiten Halbjahr, das
war 1980 damals, das Wahlfach Informatik belegt und war dann
irgendwie total begeistert vom Programmieren.
Und schreibt, dass sie dann eine Ausbildung zur
Datenverarbeitungs Kauffrau mit COBOL gemacht hat.
Und danach? Pioniere ne also.
Ja, tatsächlich ne und eigentlich auch Kobold ist ja
glaube ich wenig neue Projekte noch damit, aber war damals ganz
groß im Rennen, gerade bei großrechnern, Banken,
Versicherungen und so weiter und wird auch heute noch dort
händeringend gesucht. Schreibt weiter, dass sie dann
bis 1997 in der gearbeitet hat und dann ne Schwangerschaft und
eine Selbstständigkeit mit einer Entwicklungs Firma hinter sich
hat, die leider mit der IT Blase dann wohl auch geplatzt ist und
nicht funktioniert hat. Aber dafür konnte sich
wenigstens TLCSS und P beibringen.
Konnte das hat mich sehr überrascht.
Bei dieser Nachricht konnte dann keine Stelle mehr in der IT
finden und hat wohl ganz viele Absagen bekommen mit dem Thema,
sie sei zu alt fürs Team und sie war zu dem Zeitpunkt irgendwie
36 Jahre alt und ist also halte ich für ganz ganz groben
Quatsch, dass man 36 Jahre irgendwie zu alt ich würde mich
eher freuen, weil das ja wahrscheinlich darauf hinweist,
dass da sich jemand etwas seniores bewirbt, der auch ein
bisschen Erfahrung. Mitbringt.
Also fand ich, das fand ich so mit den verwirrenden Teil.
Jetzt kommt so ein bisschen, jetzt kommt n bisschen ne
härtere Phase, dann dann für sie, also nach einer Scheidung,
einem Zusammenbruch mit Depressionen und auch 2 Klinik
Aufenthalten. Hat sie dann.
Mitte August wieder neu gestartet.
Also erstmal herzlichen Glückwunsch.
Schaffen, dann wieder neu zu starten und dann innerhalb von 3
Monaten. In Teilzeit quasi.
Boot Camps entdeckt und dort einfach die Möglichkeit haben,
auch wieder in neue IT Themen und Programmier Fähigkeiten
einzusteigen. Und hat da sehr viele Dinge
gelernt, die noch nicht wusste und hat dann im Januar diesen
Jahres quasi über auch diese Boot Camps eine Teilzeitstelle
gefunden und dort arbeitet sie jetzt wieder mit 54 in ihrem
Traumberuf als Softwareentwicklerin, also gar
nicht typisch auch mit einigen tiefen und auch sehr viel Kraft
sich da wieder raus zu kämpfen, also dafür erstmal ganz großen
Respekt und Herzlichen Glückwunsch.
Aber fand ich auch super spannend, solche Wege von euch
im Prinzip zu hören und zu lesen, wo vielleicht die
Laufbahn nicht so. Gradlinig waren, wie das bei uns
beiden, glaube ich. Wir haben letzte Folge doch
erzählt, dass wir relativ früh wussten, dass wir in der
Informatik unterwegs sein wollen und dann auch ganz recht
geradlinige Lebensläufe, glaube ich, beide gehabt, und das hat
auch wieder gesagt, dass nicht immer geradlinig ist, auch ganz
viele Möglichkeiten, also auch unkonventionelle Möglichkeiten,
wie zum Beispiel solche Camps, gibt sich da wieder einzufinden
und jetzt auch quasi, wenn sie, wenn sie schreibt, dass ihr
Traumberuf ist. Das ist natürlich schon große,
was ganz wenige Menschen in einem Traumberuf zu arbeiten.
Mhm. Von daher vielen Dank für das
Feedback. Und auch wenn ihr uns
Rückmeldung geben wollt, immer gerne per E-Mail.
Sagt uns gerne dazu, ob wir darüber sprechen dürfen oder
nicht, mit Claudia haben wir das entsprechend abgestimmt, aber
wir würden uns auch freuen von euch natürlich weiterhin
Feedback zu bekommen. Wie schaffen wir jetzt den auf
unser eigenes Thema? Von diesem eher emotionalen
Thema auf ein technisches Thema, was wir dieses Mal haben und ich
glaube n guter guter Übergang ist hier sich damit
auseinanderzusetzen, wie kommt man halt aus so einer
Technologie Kobold in moderne Entwicklungs Technologien und
das sind so Dinge die man sich dann aneignen muss und dazu
gehören natürlich auch Entwurfs, Muster die man gerade zum
Beispiel in objektorientierten Programmierungssprachen umsetzen
kann, umsetzen muss, um halt. Eine Software zu entwickeln, die
Halt gut wart, bar gut testbar ist und die entsprechend sich
für große Projekte eignet. Und da sind wir in den letzten
Jahren immer wieder über das Thema Dependency Injection
gestolpert, vom eigenen Einsatz, aber auch in vielen Gesprächen,
es kommt immer wieder hoch und ist auch immer wieder ein Thema,
was durchaus etwas ist, was eigentlich tagtäglich von ganz
vielen eingesetzt wird, aber immer wenn der Begriff
hochkommt, dann kämpft man bisschen damit, dass einfach
auch zu logisch zu erklären, deswegen gehen bisschen
strukturiert. Durch und versuchen das Thema n
bisschen einzuführen, um auch denen, die gerade jetzt mit der
objektorientierten Programmierung einsteigen oder
schon länger damit arbeiten, aber noch nicht mit solchen
Entwurfs mustern arbeiten, einfach ein Einstieg zu geben.
Was verbirgt sich einfach hinter diesem Fancy Begriff, weil
letzten Endes ist das Prinzip dahinter relativ einfach
nachzuvollziehen, wenn man einmal strukturiert durchgeht
und hilft uns letzten Endes, wenn wir es verstanden haben,
unsere Software letzten Endes. Ware zu machen, einfacher zu
testen, einfacher Testbar zu machen und auch einfacher
erweiterbar zu machen. Und von daher liegen wir
vielleicht los damit. Was bedeutet letzten Endes auch
der Wort Begriff Dependency Injection?
Ja. Können wir mal versuchen,
bisschen zu definieren? Also ich glaube, geprägt hat das
Wort Martin Fowler in Jahr 2004 hat er zumindestens längeren
blogspot darüber geschrieben, den wir unten verlinken.
Martin Fowler sollte vielen in der Industrie ein Begriff sein,
hat ganz bedeutende Bücher wie Clean Coal und Clean
Architecture und sowas geschrieben, ist auch sehr, ist
auch sehr öffentlich öffentlichkeitswirksam
unterwegs, schreibt sehr viele blogspot, schreibt wirklich
guten Contents, allen möglichen Fragen der Software Entwicklung.
Und der hat das erste Mal glaube ich 2004 oder so wirklich in
diese Worte. Dependency Injection und auch in
ein zweites Wort, was ganz wichtig ist in Inversion of
Control gepackt und damit diese Worte geprägt, die gehören
zwangsläufig zusammen, also dependency Action und Inversion
of Control gleich nochmal dran, was genau das ist.
Wir können gleich hören, zwangsweise zusammen.
Man sagt aber mittlerweile eigentlich fast nur noch die
Pension, weil es eben so zusammengehört.
Was ist es? Es gibt jede Menge Prinzipien in
der Softwareentwicklung, die Code sauberer, Erwartbarer
machen. Also das ist Solid Prinzip.
Zum Beispiel ist vielleicht einigen ein Begriff und da kommt
darin vor, dass einzelne Klassen in der objektorientierten
Programmierung eines Single Responsibility verfolgen, das
heißt einen einzelnen Zweck haben, und das bedeutet, wenn
ich mehrere, wenn meine Anwendungen irgendwann so
komplex wird, dass ich eben in ganz viele verschiedene
Bereiche. In Bereichen Code unterteilen
muss, dann sollte ich das in verschiedenen Klassen
unterteilen. Ganz klassisches Beispiel, ich
habe einen Service, also eine Klasse, die Business Logik
enthält, die mit Daten irgendwie die Daten verarbeitet und diese
die sollte vielleicht nicht direkt mit meiner Datenbank
kommunizieren, sondern für die Kommunikation meiner Datenbank
baue ich eine weitere Klasse, man nennt das auch ein
Repository Pattern, baue also eine Klasse, die dann für mich
weiß, Ah okay meine Datenbank ist zum Beispiel Mongo DB und
die benutzt dann die Mongo DB SDK und mit der mit der
Datenbank zu kommunizieren. Und in der Realität sieht dann
so aus, dass man Service, der diese Business Logik erhält,
eine Abhängigkeit auf meine auf meinen Datenbank Repository
Cluster hat und einfach sagt Pass auf wenn immer ich Daten
brauche rede ich nicht direkt mit der Datenbank sondern auch
eine Instanz von diesem Datenbank Repository und da in
dieser Instanz wird es dann Funktionen geben wie gib mir
alle Elemente für ein neues Element hinzu Löschen Element,
bearbeite ein Update, ein Element und so weiter und der
erste intuitivste Teil, den auch viele Junior Entwickler machen,
die das erste Mal tun. Die ersten von diesen Clean Code
Prinzipien lesen und lernen. Würde ich sagen, ist der erste
intuitive Schritt zu sagen, OK, das heißt, wenn ich jetzt diese
Service Klasse die meine Business Logik hat habe, dann
gehe ich da einfach hin und als allererstes im Constructor bevor
ich hier überhaupt irgendwas anderes mache instanziiert ich
jetzt erstmal einen eine neue Instanz von dieser Repository
klasse wahrscheinlich sowie Database equals new.
Database repository. Und Speicher mir die die
Speicher mir die dann in einer privaten Variable weg, sodass
ich in meinen Funktionen wo ich Daten verarbeiten kann, eben auf
diese eigene Instanz meine Repository klasse zugreifen
kann. Das ist so ein bisschen der
Standard weg, der den meisten Leuten erstmal in den Sinn
kommt. Und was die Pendants Injection,
Universe of Control jetzt sagt, ist nein, nein, nein, nein,
nein, mach das nicht so. Was du willst, nicht dass deine
Service klasse dir eine Abhängigkeit auf diese
Repository Cluster hat. Selber eine Instanz von dieser
Daten von diesem Datenbank Repository erstellt, sondern du
willst, dass die Instanz des Datenbank Repositorys dieses
Service Klasse verwenden soll von außen herein gegeben wird im
Idealfall es gibt verschiedene Funktionen aber die Geläufigste
ist eigentlich als Parameter im Constructor, das heißt wenn
immer ich eine eine neue Instanz von meiner Service Klasse.
Stellen muss, muss ich quasi in Constructor auch mitgeben.
Stand die bereits im Voraus erstellte Instanz von all ihren
Dependencies. Man s deswegen inversion of
control, weil die. Die Service Klasse die Business
Logik enthält dann nicht mehr selber in Control ist diese
diese Dependency zu instanziieren sondern eine
bereits instanziierte dependency.
Sie bitte dann verwenden soll von außen herein gegeben
bekommt. Also das ist diese Inversion,
dass sie nicht selber das macht, sondern dass von außen jemand
anders diese Dependency rein gibt, üblicherweise über den
Constructor und die dann einfach verwendet werden kann.
Du hast vorhin gesagt, einer der Gründe, warum wir das machen,
ist diese Single Responsibility Prinzip.
Das heißt eine Klasse soll nur eine Funktion haben und diese
Funktion soll auch in sich geschlossen nutzbar sein.
Großer Vorteil ist, wir können das dann auch unabhängig von
anderen Komponenten testen und das ganze Thema Inversion of
Control und die Action hilft uns natürlich dabei, das Ganze nicht
nur in sich geschlossen zu halten, sondern auch.
Bestimmte Dinge austauschbar und flexibel zu halten.
Du hast gerade das Beispiel genannt, den Zugriff auf eine
Datenbank, aber was ist letzten Endes eine Datenbank?
Es gibt unterschiedliche Datenbank Typen und wenn ich
jetzt natürlich die Instanzierung dieser Datenbank
direkt in meinem Service mache, dann bin ich natürlich
festgelegt oder hab dort ganz viele Varianten in diesem
Konstruktor, welche Art von Daten Bankverbindung ich dort
aufbauen möchte. Wenn ich jetzt natürlich das von
außen rein gebe, dann habe ich die Möglichkeit hier auch.
Unterschiedliche Varianten von Datenbank Implementierung zu und
deswegen Dependency Injection zu Injection Hereinzugeben und
damit diese Abhängigkeiten, die man Service benötigt, nämlich
den Zugriff auf die Datenbank flexibel zu gestalten und ich
kann damit zum einen die einzelnen Datenbank Operationen
individuell testen, für jede vielleicht Datenbank Variante
die ich habe als auch meinen Service den ich hier anbiete,
diesen Repository Service und dort.
Kann ich dann entsprechend auch zum Beispiel eine gemobbte
Datenbank hinterlegen, um Dinge vielleicht auch testen zu
können, wenn diese reale Datenbank mir in diesen Test
cases gar nicht zur Verfügung steht und ein Prinzip, was in
einer Informatik Vorlesungen in der Uni auch immer gepredigt
wurde, ist das Prinzip der geringen Kopplung, das heißt,
wenn wir einzelne Komponenten entwickeln, egal ob es jetzt
einzelne Services sind oder einzelne Klassen, sollten diese
möglichst unabhängig voneinander nutzbar.
Sein und sich gegenseitig verwenden.
Aber nicht unbedingt. Gegenseitig bedingen, das heißt,
ich kann sie auch unabhängig voneinander verwenden.
Und wenn ich jetzt wirklich eine neue Instanz dieses Services
erstelle, kann ich dort unterschiedliche Dinge
entdeckten, um halt verschiedene Use Cases zu adressieren.
Genau, ich stelle. Stell dir vor, ich möchte andere
Datenbank Technologie in Zukunft verwenden, also nicht mongo DB,
sondern ich möchte irgendwie migrieren auf irgendwas anderes,
dann würde ich ja völlig ausreichen nur dieses Datenbank
Repository im Code anzupassen und der Service die Business
Logik erhält kriegt im Idealfall davon überhaupt gar nichts mit,
weil der ja ohnehin einfach nur vom Repository Methoden gibt mir
alle Elemente für ein neues Element zu löschen, Element und
so weiter verwendet, aber das hat jetzt nichts geändert, so
dass generell einfach solid lose Kopplung und und.
T Code. Und was Sie beachten aber sagt
ist das solltest du ESO machen und dann aber halt eben von
außen eine Instanz reingeben und es gibt auch ganz viel Kritik
daran, da können wir auch gleich nochmal zu, aber die Testbarkeit
die du gerade angesprochen hast, die ist für mich auch so der
größte Punkt warum ich das zum Beispiel in all meinen Projekten
auch schon seit langer, langer Zeit immer so mache, das finde
ich, schlägt für mich auch alle Kritikpunkte, die wir gleich
noch mal besprechen ist, dass diese große Testbarkeit jedoch
reinkam, reinkommt, da sich eine wie du gesagt hast.
Fake eine Mark Datenbank in den Test Reihen geben kann.
Wenn ich meine Business Logik Klasse teste und gar nicht
wirklich gegen eine Datenbank kommunizieren, sondern einfach
faken kann, was passieren soll, wenn E wenn diese wenn diese
wenn diese Business Logik einfach mir alle Elemente
aufruft, dass ich das eben ganz isoliert testen kann, ist für
mich einer der größten Benefits von Dependency Injection.
Ein Beispiel einfach, ob das greifbarer zu machen, was ich
gerne geben würde, was ich super gut fand in dem youtube Video zu
dependency injection. Vom David Thielke eine Analogie
zum Einkaufen, das heißt eben nicht, ein Einkaufs Service
baue. Dann kann ich diesen Service
sagen, was soll der? Der Service letzten Endes für
Produkte beschaffen und am Ende möchte ich aber völlig flexibel
sein in denen, wo letzten Endes dieser Einkaufs stattfindet.
Das heißt, wenn ich dir sage, bitte kauf mir eine Cola, dann
möchte ich nicht, dass du immer in dem gleichen Laden läufst,
sondern du sollst frei entscheiden, welcher Laden ist.
Derjenige, der gerade bei dir am nächsten ist.
Weil sobald ich das Hard Code in dieser Einkaufs Klasse zum
Beispiel kaufe, Cola bei Lidl, dann musst du immer nach Lidl
gehen, auch wenn der nächste Supermarkt.
Netto oder Aldi ist. Und wenn ich jetzt eine klasse
Bau, wo ich diese Abhängigkeit, nämlich wo letzten Endes der
Einkauf stattfindet, injection kann, dann kann ich je nach
Szenario wo wir uns gerade befinden, die den Auftrag geben
G einkaufen. Und wenn du dann halt
zufälligerweise einen Lidl zur Verfügung hast, kann ich dann
den Lidl Service Injection und wenn du in der Nähe vom Aldi
bist kann ich den Aldi Service Injection, das heißt ich kann
dann wirklich sehr flexibel auch auf verschiedene Laufzeit
Umgebung reagieren. Und mich darauf entsprechend
einstellen. Und wenn ich teste, kann ich
eben irgendein Fake Supermarkt in checken.
Wenn ich genau weiß, wie er in die sich in diesem Test verhält,
weil ich ja gar nicht testen will, ob der Supermarkt
funktioniert, sondern ob ein Einkaufs Service funktioniert.
Ne, und das ist ja Dienstbarkeit, aber man merkt
schon in den meisten Programmiersprachen läuft das
aber dann darauf hinaus, dass man das, was auch immer da rein
injected wird, gar nicht genau definiert, sondern dass einfach
eine Abstraktion von irgendwas ist.
Also in der Java und dot net heißt, das Interface zum
Beispiel ne, also dass ich einfach sage, ich definiere.
Was eine Abhängigkeit können muss, ist eigentlich Interface.
Nichts als Vertrag definiert, was auch immer du mir da rein
gibst. Muss eine Funktion haben.
Alle Elemente abholen, ein Element löschen, Element Update
und ein neues Element hinzufügen und wie du das Implementierst.
Ob das jetzt wirklich gegen Mongo DB geht, ob du das Fakest,
ob das gegen andere Datenbank geht interessiert mich nicht.
Alles was wir vereinbart haben ist, ich bekomme von dir
irgendwas rein injected also i eine eine Implementierung eines
Interfaces wenn man in diesen Sprachen bleibt bekomme ich von
der E rein injected und solange das diese Methoden anbietet die
ich erwarte weiß meine Business Logik.
Gar nicht, was da jetzt wirklich passiert.
Und in diesem Supermarkt Analogie zu bleiben, das heißt,
ich definiere einmal, was kann ein Supermarkt, also ich kann da
ein Item aus dem Regal nehmen, ich kann einem ein bestimmtes
Item suchen, also einen Apfel suchen, den aus denen egal
nehme, ich kann zur Kasse bringen, ich kann den bezahlen,
dann habe ich den, und dass diese Anforderungen erfüllen ja
nahezu alle Supermärkte da draußen, das heißt, ich kann
meine Business Logik, diese Elemente reingeben, wenn meine
Business Logik jetzt einen einkaufszettel.
Umzuwandeln in tatsächliche Ware also, die weiß ich nicht.
Items für den Einkaufszettel durchzugehen und dann an den
Supermarkt die Befehl zu schicken, wenn Apfel drauf
steht, einen Apfel zu nehmen, einen Apfel zu bezahlen und so
weiter. Dann ist das ja für meine
Business Logik völlig ausreichend und testen kann ich
dann natürlich mal simulieren, wie es denn wäre, wenn kein
Apfel zur Verfügung steht oder wenn es nur Birnen gibt oder was
weiß ich man Alternativen programmiert.
Deswegen abstrahiert man das in der Regel und häufig heißen
diese Abstraktion neben Interfaces.
Und du hattest gesagt, Interfaces haben irgendwie den
Vertrag, den zugrundeliegenden Service, Contract oder Contract,
je nachdem in welcher Sprache man sich da befindet und
definieren Dadrüber welche Funktionalitäten hier zur
Verfügung. Verstehen.
Das bedeutet, wenn ich die Pence Injection mit einer Sprache
implementiere, die diese Art von Interfaces unterstützt, egal ob
es jetzt irgendwie Java, C, Sharp oder andere Sprachen sind,
dann kann ich tatsächlich hingehen und mit den Basis
Funktionalitäten dieser objektorientierten
Programmiersprache die Perception implementieren und
tatsächlich in der Form implementieren, wie es
ursprünglich mal gedacht war. Das heißt, ich gehe hin und
definiere diese Verträge und kann dann.
Bestimmte Klassen implementieren, die diesen
Vertrag erfüllen und kann dann, egal ob ich jetzt den Service
für die Mongo DB oder den Service für die Oracle DB habe,
kann ich diesen dann Injection in meinen entsprechenden Dienst?
Natürlich kann ich das manuell machen, aber viele die sich
heute damit beschäftigen und ich glaube, wenn du jetzt hingehst
und nach irgendwie dependency Injection Programmiersprache X
suchst, online willst du die ersten 20 Ergebnis.
Ergebnisse bekommen mit irgendwelchen Frameworks und
Tool Kits, die du nutzen kannst, um in dieser Technologie
Dependency Injection Anführungsstrichen einfacher zu
machen und ich glaube das ist ein Thema, woran sich letzten
Endes auch n bisschen da die Verwirrung rund um den Begriff
ergibt, weil halt das die Sache zumindest für Einsteiger häufig
eher komplexer als einfacher Macht und natürlich da viel
Abstraktion reinbringt in ein Prinzip.
Das an sich, wir haben es gerade beschrieben, super simpel ist.
Genau, denn Dependency Injection ist eigentlich nichts anderes.
Als über den Constructor diese Dependance mit einzugeben, aber.
Was ist denn jetzt, wenn meine Dependencies auch wieder
dependencies haben, wenn zum Beispiel meine, meine, meine
Datenbank Repository the Dependency hat auf das auf das
Mongo DB SDK und wenn das wiederum Dependency irgendwas
anderes hat, dann können diese dependency Graphen sehr komplex
werden und das bedeutet, ich möchte eigentlich gerade nur mal
die, die die Klasse mit meiner Business Logik instanzieren muss
aber vorher 5 6 vielleicht 15 verschiedene andere Klassen.
Präsentieren die sich dann also nicht erst mal 2.
Klasse Instanziieren, damit ich das Mongo DSTK haben, kann ich
diese beiden Klassen rein gebe, dann muss ich dienen, dass die
Repository klasse Instanzieren wo ich dann.de reingehen kann
und so weiter also heißt es kann sehr sehr sehr sehr sehr komplex
werden diese großen dependency Graphen, gerade wenn ein Projekt
sehr groß und umfänglich ist. Und um das Problem zu lösen,
dass sich das nicht irgendwie jedes mal mir 1000 Gedanken
machen muss, gibt es Frameworks, die eine automatische Dependency
Action mit sogenannten Containern und Service Location
machen. Und was das ist, ist im Prinzip,
ich habe eine große Registry, wo ich alle meine Klassen, die
irgendwas mit Dependancen Jacksons zu tun haben, also die
entweder selber dependency sind oder die Dependencies haben, an
einer großen zentralen Stelle registriere und dennoch quasi
sage Pass auf, das war eine Klasse, das ist der Constructor,
der verwendet werden soll da. Wenn du also damit du die
eingeben kannst und dann bringen diese Frameworks einen Service
locator, so heißt das mit der dann quasi sagt dem ich dann
quasi sagen kann, hey, ich möchte jetzt bitte eine Instanz
von meiner Einkaufs Klasse haben oder von meiner von meinem
Service der meine Business Logik haben und was dann dieser
Service Locator macht ist er schaut sich den Constructor an,
weiß also welche Dependencies ich brauche, schaut ob die auch
alle vorher irgendwo irgendwo registriert waren in dieser
Registry wenn ja schaut sich an welche Dependencies diese
brauchen. Und Instanziiert dann diese
Kette einen Schritt nach dem anderen durch und gib mir dann
nachher einfach eine fertige Instanz von meiner Business
Logik klasse rein oder vielleicht sogar eine Singleton,
wenn nicht definiert habe, dass ich davon nur eine einzige
Instanz globale meinem System haben möchte.
Da gibt es mir Dienstag heraus, wenn ich danach frage, aber
diese diese Frameworks nehmen wir einfach dann die große
Arbeit ab, dass ich, dass ich nicht diese dependency chain
jedesmal manuell wieder auflösen muss, sondern dass ich einfach
einmal alles registriere, Sage, was sind die zu verwendenden
Constructor. Und dann kann ich eben diese
Frameworks einfach fragen nach Hey, gib mir doch mal bitte eine
Instanz von meiner sowieso klasse und unter der
Voraussetzung, dass alle Dependencies und deren
Dependencies registriert habe in
dieser Registry. Diese Container macht man
üblicherweise, wenn die App startet.
Unter der Voraussetzung, dass da eben alles registriert ist,
bekomme ich dann auch eine fertig richtig instanziierte
Instanz und kann dadurch natürlich auch steuern.
Wenn ich jetzt morgen die Datenbank Technologie wechsle,
könnte ich einfach eine andere Datenbank Technologien der
Registry registrieren und trotzdem würde alles weiterhin
aufgelöst werden. Die Frage ist jetzt, brauche ich
solche Frameworks oder kann ich letzten Endes das Ganze auch
händisch implementieren. Und ich glaube es wie bei allen
Abstraktionen die Frage, wie groß und komplex ist meine
Anwendung, lohnt es sich, dass ich mich in so einer Technologie
eine zusätzliche Technologie, eine zusätzliche Attraktion
einarbeiten, um dann letzten Endes in der Entwicklung und in
der Wartung Komplexität rauszunehmen, aber am Anfang
muss ich mich in diese neue Technologie einarbeiten.
Man muss natürlich auch dazu sagen, dass bestimmte
technologienwie.net. Vor halt das Prinzip von
Dependency Injection schon out of the Box mitbringen.
Das heißt, viele Dinge funktionieren da schon Bild in,
aber die Frage ist, an welchem Punkt sollte ich mir jetzt
darüber Gedanken machen, solche. Ja, solche Abstraktionen
einzusetzen und mein Projekt darum zu ergänzen.
Mhm. Ich würde erst mal anfangen, wie
immer. Also ich persönlich verfolge
eigentlich immer gerne die Strategie, dass so ein
Framework, dass ich so frag, erst dann holen sollte, wenn
das, wenn ich das Problem habe, was löst.
Wenn ich jetzt, wenn ich ein sehr simpler dependency Graphen
habe, brauche ich das in der Regel nicht.
Und das ist auch eigentlich so. Also die Hauptkritik, es gibt
sehr viel Kritik an diesen Frameworks, die meiste Kritik
richtet sich aber eigentlich immer gegen diese Container und
Service locator, wenn man Kritik an Dependency Injection und
Inversion of Control hört, ist eigentlich fast immer ein
Framework gemeint. Ich glaube, es steht außer
Frage, dass man die Panels Injection macht.
Ob ich das aber mit einem Framework mache, das hängt
wahrscheinlich daran, wie komplex meine Dependency Chain
ist und viele sagen auch eine Komplexe, eine sehr eine zu
komplexe Dependency Chain ist schon ein Anti Pattern, bedeutet
schon schlechte Kapselung und werfen diesen Frameworks
natürlich vor, dass sie gerade unerfahrene Entwickler innen und
Entwicklern genau das fördern, indem ich einfach total egal wie
komplex. Deine Dependency Chain wird
registriert. Einfach alles an dir alles
einmal an diesem Container und dann kannst du einfach den
Service rausnehmen, wird dann richtig zusammengebaut und das
ja, das bedeutet manchmal vielleicht, dass sich ein 2
Gedanken zu wenig macht im zumindest an der Perspektive von
den Kritikern davon und dann einfach sagen, ja, vielleicht
solltest du auch mal schauen warum dependency Graphen so
verdammt komplex ist, dass dieses Framework brauchst.
Vielleicht ist das aber auch schon ein Fehler und eine eine
Komplexität, die du verstecken kannst mit diesen Frameworks.
Die aber trotzdem Code Smell ist, die aber trotzdem
vielleicht eine Wartbarkeit irgendwie nicht ganz, also nicht
nicht wirklich fördert. Weil du eben diese Frameworks
einfach diese Magic für dich machen.
Und ich glaube, gerade wenn man in eine Technologie neu
einsteigt, ist es immer sinnvoll, möglichst viel auch
selber zu implementieren. Von diesen Patterns und sich da
nicht auf zu viel Magie zu verlassen, weil das natürlich
einiges weg abstrahiert, was einem dann letzten Endes nicht
ermöglicht, wirklich auch den Mehrwert eines bestimmten
Entwurfs Musters auch zu erlernen und auch auszunutzen
und einen Punkt gerade bei dependency Action ist natürlich,
dass wir höchst testbare. Komponenten bauen wollen.
Und wenn wir da natürlich über solche Frameworks arbeiten,
machen wir uns das testen auch wieder schwieriger.
Das bedeutet, ich muss dann auch das berücksichtigen, wenn ich
dann solche Technologien einsetze.
Total. Das ist ein, das ist ein richtig
guter Punkt. Ich mache also, weil es ist
einfach schwierig, diese Frameworks zu testen, ich es
eigentlich fast nicht möglich, diesen also schon möglich, aber
einfach ja nicht ganz trivial und auch nicht immer wird nicht
immer gemacht, dass eben dieses Framework diesen Locator
wirklich selber. Teste, und das ist ja eigentlich
die freie Sicht, muss aber eigentlich muss ich testen, ob
ich denn da alle Dependencies richtig registriert habe und ich
muss eigentlich auch testen, ob das ob der richtige Konstruktor
verwendet wird beim Zusammenbauen dieser
Dependencies und sowas und das ist auch einer der großen
Kritikpunkte, dass das alles wegfällt, denn.
Das ist auch problematisch und das ist mir auch schon passiert.
Ein großes Problem von diesem Service Location ist das
fehlende Registrierungen daran oft erst zur Runtime auffallen.
Also das ist ne der wenn ich das Kompilieren sieht das alles gut
aus und in dem Moment wo mein Code das erste Mal so eine
Klasse zusammenbauen möchte über einen Service locator und dann
aber die eine irgendeine Dependency oder Sub dependency
oder sub dependency nicht registriert ist knallt das gibt
mir Exception und mein ganzes irgendwann ganze Programm stürzt
ab wenn ich halt selber diese Dependency zusammenbauen.
Dann kann ich natürlich im Konstruktor sicherstellen, dass
alles da ist, weil ich ja diese Variablen selber.
Natürlich definiere, wohingegen ich mich darauf verlassen muss,
dass das auch richtig, richtig registriert wurde, denn es fällt
erst zur Runtime auf. Es fällt üblicherweise nicht in
Unit oder integrations Tests auf, sondern wirklich erst wenn
das Ding gestartet ist. Weil ich bei Unit und
Integration Tests ohnehin vielleicht sogar ohne Locator
mache, weil ich mir die selber reingeben möchte, das heißt das
ist auf jeden Fall ein Punkt, den man im Hintergrund sollte,
wie teste ich das, wie stell ich denn sicher, dass sich alle
meine mal alle meine Services auch richtig instanziieren
lassen? Ich glaube, zusammenfassend
lässt sich sagen und du hattest vorhin schon erwähnt, dependency
und in Inversion of Control sind Dinge, die man tun sollte.
Man kann einfacher testen, von daher auf jeden Fall anschauen
und machen, wenn man es noch nicht tut, aber bei den
Frameworks sollte man schauen, hilft es mir wirklich, also
hilft es mir die Komplexität zu reduzieren oder erzeuge ich
dadurch einfach durch die Abstraktion Mehraufwand für mich
und ich glaube das muss man individuell nach jedem Projekt
für jedes Projekt selber entscheiden und ich fand
eigentlich gerade das was du gesagt hattest sehr gut.
Erstmal ohne zu starten und an dem Punkt wo man eine
Herausforderung erreicht und sagt, jetzt habe ich ein
Problem, was ich so nicht so einfach lösen kann, sich
anzuschauen ist dann so eine Technologie so ein Framework das
richtige finde ich finde ich super spannend und hat mir auf
jeden Fall jetzt auch noch ein bisschen geholfen das Thema
einfach nochmal zu reflektieren, weil mittlerweile ist es in
vielen Technologien einfach irgendwie auch schon weg
abstrahiert oder ist es irgendwie so zum Standard Pfad
geworden den man so mit lernt wenn man eine Technologie
einsteigt und sich das einfach noch mal so bewusst vor Augen zu
führen, so wie man es vielleicht tut, wenn man zum ersten Mal an
eine neue objektorientierte Programmiersprache kennenlernt,
fand ich in dem Fall sehr hilfreich und da würde uns
natürlich interessieren, ist das für euch spannend, wollt ihr
auch weitere Folgen haben zu den Thema Architektur Patterns
entwicklungsmuster, dann schreibt uns gerne e Mail oder
hinterlassen Kommentar geht auf Spotify relativ einfach das zu
wissen was welches Thema interessiert euch sollen wir
mehr über solche Themen sprechen oder ist das etwas, was ihr
ohnehin schon jeden Tag einsetzt und das war jetzt für euch?
Super langweilig, interessiert und so einfach.
Genau und generell immer daran denken, so Debatten um so
Frameworks, die werden sehr emotional geführt und da gibt es
auch alle möglichen Artikel und Videos, gerade aus Miguel Casa,
der großer Verfechter davon, dass das alles, dass das voll,
das dass der Teufel das gemacht hat, ich glaube, da ist schon
relativ klar, dependency Action sich o sind absolute No Brauner,
allein schon wegen der Testbarkeit hatte ich eingangs
erwähnt und Debatte um so Frameworks, das muss man sich
selber angucken, ich bin ich gerne so bisschen Punkt OK also.
Ne, wenn es zu viel Magic ist, ist das für mich schwierig, denn
Magic ist cool, wenn sie funktioniert und die absolute,
wenn sie nicht funktioniert und Magic macht es auch hart Bugs zu
finden und irgendwelche Dinge zu meinen.
Wenn man das Gefühl, dass man das gut kontrolliert, kann man
das einsetzen, ist aber auch was an neuen Entwicklerteam
natürlich bringen muss, wenn man Framework verwendet, aber
generell mal ohne starten und dann einfach schauen, aber
generell halb so wild, die Debatte wird wie immer in der IT
sehr emotional geführt, sehr religiös.
Steht da irgendwo den heiligen Schriften von Spring Boot und
von USB und dass man das verwenden muss, einfach mal
vielleicht einen Blick entwickeln.
Sehr cool. Und wenn ihr euch diese Folge
genauso gut gefallen hat wie mir, lass uns gerne eine
Bewertung, da könnt ihr auf Spotify oder Apple Podcasts
machen und natürlich freuen wir uns auch sehr über alle, die uns
wie vorhin schon genannt, auf einen Kaffee einladen.
Das ist etwas, wo wir uns immer extrem freuen, falls ihr lieber.
Und anders, was Gutes tun wollt, schaut mal in unseren Shop rein,
da gibt es auch unsere Kaffeetassen.
Findet ihr natürlich wie immer in der Beschreibung.
Dann bleibt uns nicht viel zu sagen übrig, als zu sagen, heute
ist der Wurm drin, dann bleibt uns nicht viel übrig, als zu
sagen, vielen Dank fürs Zuhören, habt eine gute Zeit, genießt die
nächsten 2 Wochen, denn der Tochter scheint alle 2 Wochen
jeden Montag bis dahin viel Spaß mit die Pension schreibt R Code
und Hub gezeigt. Bis dahin.