Ich finds super, dass Du für so grundlegende aber oft übersehene Architekturkonzepte eine deutschsprachige Erklärung lieferst. +1 An mancher Stelle (zB bei dieser Episode) würde aber eine ganz einfache Illustration (zB mit Pfeilen zwischen den Klassen als Marker für die Abhängigkeit) Bände sprechen und noch mehr Leute abholen. Architektur Konzepte sind nunmal der natur nach eher Abstrakt und ein Bildchen macht es viel konkreter.
Vielen Dank für Dein tolles Feedback, das freut uns sehr 😊 Ich kann Deine Anregung gut nachvollziehen - der Punkt dabei ist leider ein bisschen die Zeit, die wir für die Videos haben. Und wenn man ansprechende Grafiken haben will, ist das leider schon ein ganzes Stück mehr Aufwand … also ich sage nicht, dass das nicht schön wäre, es ist nur zeitlich im Moment nicht anders lösbar. Aber vielleicht tut sich daran in Zukunft noch etwas 😊
Cooler Kanal. Obwohl ich in Pension bin, also nix mehr tun muss :) , werd' ich mir einige Sachen anschauen, weil Interessenates kurz und prägnant erklärt wird. Ich bin beeindruckt.
Also wenn wir z.B. einen Sportler haben, der einen Trainer erwartet, dann sagen wir dass er nicht einen bestimmten Trainer (z.B. Jogi Löw) erwartet sondern einfach irgendeinen Trainer, damit er nicht mehr nur abhängig ist von Jogi Löw?
[gr] Vielen Dank für Dein Feedback und das Lob 😊 Was Deine Frage angeht: Nein, die Begriffe sind nicht identisch - Dependency-Inversion besagt zunächst einmal nur, dass die Abhängigkeiten von Außen in eine Komponente hineingelangen, aber nicht, wie das konkret erfolgt. Dependency-Injection ist dann ein möglicher Ansatz, wie man Dependency-Inversion konkret umsetzen kann (ein anderer wäre zum Beispiel die Nutzung eines Service-Locators).
[gr] In gewissem Sinne ja … Bei der Factory geht es ja im Prinzip darum, dass eine Instanz zu einem gegebenen Interface erstellt wird, ohne dass Du als Verwender weißt (oder wissen müsstest), von welcher konkreten Klasse diese Instanz erzeugt wird. Bei dem Dependency-Inversion-Prinzip hast Du auch die Konstellation, dass in eine Klasse (oder eine Funktion) eine bestehende Instanz hineingereicht wird, die ein Interface erfüllt, wo Du aber nicht weißt, von welcher konkreten Klasse diese Instanz abstammt. Das heißt, beiden Patterns ist gemein, dass ein Interface verwendet wird, um zu abstrahieren. Bei der Factory geht es aber um die Erzeugung der Instanz, bei Dependency-Inversion nur um die Übergabe. Insofern haben die einen unterschiedlichen Schwerpunkt.
[gr] Ich habe nicht aus dem Stegreif im Kopf, wie das Pattern im Detail definiert ist, aber IMHO ist die Aussage des Patterns nur, *dass* man Dependencies von Außen hereingeben sollte statt sie von Innen aufzulösen. *Wie* man das macht, ist ein Implementierungsdetail (und da gibt es ja tatsächlich auch eine ganze Reihe von verschiedenen Ansätzen, sei es ein Service-Locator oder ein DI-Container, und die Unterscheidung zwischen Constructor- und Property-Injection). Du hast für die Praxis natürlich Recht, dass es eine essenzielle Frage ist, wer die Implementierung erzeugt - ich bin mir nur wie gesagt nicht sicher, ob das für die Definition des Patterns an sich relevant ist.
Stimmt, ein Beispiel ist das Spring Framework als DI-Container. Hier wird die Interface Implementierung mit @Service annotiert, wodurch diese Klasse als Bean erzeugt und von diesem Container verwaltet wird. Da der Container sicherstellt, dass die Beans zum Programmstart verfügbar sind, können diese für die Depedency injection verwendet werden.
Ich finds super, dass Du für so grundlegende aber oft übersehene Architekturkonzepte eine deutschsprachige Erklärung lieferst. +1
An mancher Stelle (zB bei dieser Episode) würde aber eine ganz einfache Illustration (zB mit Pfeilen zwischen den Klassen als Marker für die Abhängigkeit) Bände sprechen und noch mehr Leute abholen. Architektur Konzepte sind nunmal der natur nach eher Abstrakt und ein Bildchen macht es viel konkreter.
Vielen Dank für Dein tolles Feedback, das freut uns sehr 😊
Ich kann Deine Anregung gut nachvollziehen - der Punkt dabei ist leider ein bisschen die Zeit, die wir für die Videos haben. Und wenn man ansprechende Grafiken haben will, ist das leider schon ein ganzes Stück mehr Aufwand … also ich sage nicht, dass das nicht schön wäre, es ist nur zeitlich im Moment nicht anders lösbar.
Aber vielleicht tut sich daran in Zukunft noch etwas 😊
Cooler Kanal. Obwohl ich in Pension bin, also nix mehr tun muss :) , werd' ich mir einige Sachen anschauen, weil Interessenates kurz und prägnant erklärt wird. Ich bin beeindruckt.
[gr] Vielen Dank, das freut mich - ich wünsche Dir viel Vergnügen 😊
Also wenn wir z.B. einen Sportler haben, der einen Trainer erwartet, dann sagen wir dass er nicht einen bestimmten Trainer (z.B. Jogi Löw) erwartet sondern einfach irgendeinen Trainer, damit er nicht mehr nur abhängig ist von Jogi Löw?
[gr] Ja, genau 👍
hallo, danke für das tolle Video. Sind eigentlich die Begriffe dependency inversion und dependency injection identisch?
[gr] Vielen Dank für Dein Feedback und das Lob 😊
Was Deine Frage angeht: Nein, die Begriffe sind nicht identisch - Dependency-Inversion besagt zunächst einmal nur, dass die Abhängigkeiten von Außen in eine Komponente hineingelangen, aber nicht, wie das konkret erfolgt. Dependency-Injection ist dann ein möglicher Ansatz, wie man Dependency-Inversion konkret umsetzen kann (ein anderer wäre zum Beispiel die Nutzung eines Service-Locators).
Scheint so ähnlich zu sein wie das Design Pattern der Fabrikmethode.
[gr] In gewissem Sinne ja …
Bei der Factory geht es ja im Prinzip darum, dass eine Instanz zu einem gegebenen Interface erstellt wird, ohne dass Du als Verwender weißt (oder wissen müsstest), von welcher konkreten Klasse diese Instanz erzeugt wird.
Bei dem Dependency-Inversion-Prinzip hast Du auch die Konstellation, dass in eine Klasse (oder eine Funktion) eine bestehende Instanz hineingereicht wird, die ein Interface erfüllt, wo Du aber nicht weißt, von welcher konkreten Klasse diese Instanz abstammt.
Das heißt, beiden Patterns ist gemein, dass ein Interface verwendet wird, um zu abstrahieren. Bei der Factory geht es aber um die Erzeugung der Instanz, bei Dependency-Inversion nur um die Übergabe. Insofern haben die einen unterschiedlichen Schwerpunkt.
Klasssssssse
[gr] Danke 😊
da fehlt was ! Wer erzeugt die Implementierung vom Interface? Das ist ein wesentlichler Bestandteil vom DI
[gr] Ich habe nicht aus dem Stegreif im Kopf, wie das Pattern im Detail definiert ist, aber IMHO ist die Aussage des Patterns nur, *dass* man Dependencies von Außen hereingeben sollte statt sie von Innen aufzulösen.
*Wie* man das macht, ist ein Implementierungsdetail (und da gibt es ja tatsächlich auch eine ganze Reihe von verschiedenen Ansätzen, sei es ein Service-Locator oder ein DI-Container, und die Unterscheidung zwischen Constructor- und Property-Injection).
Du hast für die Praxis natürlich Recht, dass es eine essenzielle Frage ist, wer die Implementierung erzeugt - ich bin mir nur wie gesagt nicht sicher, ob das für die Definition des Patterns an sich relevant ist.
Stimmt, ein Beispiel ist das Spring Framework als DI-Container. Hier wird die Interface Implementierung mit @Service annotiert, wodurch diese Klasse als Bean erzeugt und von diesem Container verwaltet wird. Da der Container sicherstellt, dass die Beans zum Programmstart verfügbar sind, können diese für die Depedency injection verwendet werden.