Dependency Injection

Подписаться 17 тыс.

Просмотров 18 тыс.

50% 1

Dependency Injection kann in zahlreichen Sprachen wie C#, Java (Spring Boot, Android), Python, JavaScript oder PHP genutzt werden. Mit Dependency Injection, Entkopplung und Inversion of Control kannst Du Deine Softwarearchitektur verbessern und somit die Softwarequalität steigern. In diesem Video zeige ich Euch nicht nur was Dependency Injection ist, sondern auch welches Problem damit gelöst werden soll und was die Theorie hinter dieser Technik ist.
▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬
Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)
▬ Empfohlene Videos zum Thema Dependency Injection ▬▬▬▬▬▬▬▬▬▬▬▬
Wie viel Softwarequalität Ihr braucht - • Architekturen - Von Mo...
Warum Software unwartbar wird - • Warum Software unwartb...
Architektur - Modularisierung - • Architektur - Modulari...
Was ist Architektur - • Was ist Architektur?
Warum Architektur - • Warum Architektur für ...
▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬
Abonniere meinen Kanal: / @davidtielke
Alle Videos: / @davidtielke
▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
► Twitter: / davidtielke
► Xing: www.xing.com/profile/David_Ti...
► LinkedIn: / david-tielke-06140912b
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Наука

Опубликовано:

21 апр 2020

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 72

@DavidTielke 4 года назад

Wenn Euch das Thema interessiert, solltet Ihr den Kanal abonnieren - zu dem Thema gibt es in den nächsten Tagen / Wochen noch mehr Videos!

@DJone4one 2 года назад

es hat mich schon interessiert, aber die aufgabe wurde nicht zuende gemacht und das mit der ...= new Mongo...(); wird bei mir als Fehler angezeigt. Da fällt es mir persönlich schwer, welche "verknüpfung" ich dort herstellen muss. Da MongoRepos.(); ja nirgendwo mehr genutzt wird.

@fluidbaken7553 4 года назад

Die beste und verständlichste Erklärung (Einführung), die ich zu diesem Thema gehört habe.

@DavidTielke 4 года назад

Vielen Dank, das freut mich sehr :)

@tseibert78 2 года назад

Dem kann ich zustimmen; Bier und Chips haben eine eingängige Wirkung, wie gut das wir das entkoppeln und ich das Bier nicht von LIDL holen muss.

@holgerdoring6793 2 месяца назад

Ein ganz wertvolles Video!!!! Herzlichen Dank, David!

@nazissindharam4335 2 года назад

Das ist mit Abstand das beste Video zu Dependency Injection

@DavidTielke 2 года назад

Hallo, vielen Dank für das Feedback, das freut mich sehr! Gruß David

@SkyNetDeveloper 2 месяца назад

Geniale Erklärung ! Danke

@sasu1337 7 месяцев назад

Super Erklärung, super Video. Hat mir sehr geholfen, vielen Dank dafür

@xykflo 3 года назад

Super Video, vielen Dank dafür. Durch dein Vorgehen habe ich nicht nur mehr von DI verstanden, sondern nebenbei das erste Mal das Gefühl das Konzept der Interfaces zu verstehen, da du Themen und Konzepte in einen Zusammenhang bringst. Etwas was Tutorials häufig schmerzlich vermissen lassen. Daumen ist da, Abo auch und deine Videos werden meine Playlist sein.

@marcoexe11 3 года назад

Mir ging es gleich, nach diesem Video versteh ich wieso es Interfaces (zur Kappselung) gibt. =)

@DavidTielke 3 года назад

Hallo und schön das Dir (bzw Euch) meine Videos gefallen - das motiviert direkt zu mehr Videos :) Gruß David

@matthiaslochner7590 2 года назад

Danke für die Einfache und tolle Erklärung eines (für mich lange Zeit) komplexen Themas

@fco4711 3 года назад

Großartig erklärt :). Wenn man technisch in Begrifflichkeiten drin ist, so ist die Erklärung absolut hilfreich.

@Poperzenknarz Год назад

Absolut Bombe. Ich lern soviel durch diesen Kanal. Du bist auch der Grund, wieso ich mir die DotnetPro abonniert habe. Weiter so und vielen Dank :)

@danielgruner Год назад

Großes Dankeschön! Waren ein super Auffrischer und sehr gute Beispiele (besonders auch das große Projekt). Das mit den Interfaces ist echt klasse. Man weiß endlich, was man bekommt. 😂

@Aalii6 5 месяцев назад

Klasse Video - sehr relevant und verständlich! 👍👍

@aristor2926 3 года назад

Sehr gute Arbeit. Alles verständlich und detailliert erklärt. Wichtige Punkte mehrmals Erläutert. Das Video ist super zum Lernen geeignet. Vielen Dank.

@DavidTielke 3 года назад

Hey, vielen Dank, - sehr gerne! schön das es Dir gefällt! Gruß David

@guysome3263 2 года назад

Jetzt verstehe ich auch endlich warum beim Erben von Interfaces in Java immer von "Verträgen" geredet wurde, die dann in der abgeleiteten Klasse implementiert werden mussten. "Abhängigkeit gegen Kontrakte sind keine wirklichen schlechten Abhängigkeiten." Echt gut wie sich das Puzzle langsam zusammenfügt.

@DavidTielke 2 года назад

Hey, schön das ich mit dem Video etwas zu dem Verständnis beitragen konnte - bleib dran :) Gruß David

@gabsen61 2 года назад

echt super erklärt, danke!

@andreimikhalkevich5633 Год назад

Respect !!! sehr gut erklärt

@wickedsmith5997 2 года назад

sehr umfangreich und gut erklärt....sauber !

@DavidTielke 2 года назад

Danke für das Lob!

@sral8769 10 месяцев назад

35:38 Gegenmeinung: You will never gonna need it. Wenn es für ein Interface sowieso nur eine Implementierung gibt, eine Factory methode sowieso immer nur den gleichen Typ (oder singleton-object) zurückggibt sollte man sich den aufwand sparen. Sobald es aber zwei funktionalitäten gibt kann man das einbauen ... was ich erlebt habe das viel zu viel energie in Dinge gesteckt wird die man mal brauchen könnte aber die nächsten 10 jahre doch nicht braucht ...

@bookswiper Год назад

Echt tolles Video. Jetzt habe ich es verstanden

@manuelmair1855 Год назад

Absolut spitze! Danke dafür! Ich bin fast verzweifelt am Aufbau eines Repository. Funktionierenden Code findet man viel, aber eine gute Erklärung dazu leider nicht! Vielen vielen Dank!

@Videokritiker78 2 года назад

Sehr gutes Video! Vielen Dank dafür!

@DavidTielke 2 года назад

Hallo, vielen Dank, schön wenn es Dir gefällt. Gruß David

@DjNemas 2 года назад

Vielen Dank, 1A erklärt. Abo ist da. :)

@florianb.9367 Год назад

Richtig richtig tolles Video, danke dir dafür! Hast mein Abo auf alle Fälle 🙌🙌🙌🙌😎

@user-ir6yn1uo8w 10 месяцев назад

Sehr schön! Ich dachte, ich wüsste schon alles drüber, aber es hat wirklich Spaß gemacht, es auf diese Art zu hören. Nichts gegen "Chipse", aber "Receipt" spricht man völlig anders aus. ;-)

@timothy3882 2 года назад

Vielen Dank für die klasse Erklärung. habe gerade für meine anstehende Klausur ein wenig gesucht, da die Beispiele im Skript nicht immer ganz so schön erklärt sind. Also vielen Dank. Ich werde wohl in Zukunft mehr von deinen Videos schauen. --> Aboooo Lg ;)

@DavidTielke 2 года назад

Hey Timothy, sehr cool, danke für das Lob und viel Erfolg bei Deinen Klausuren! Gruß David

@frankmuller6227 Год назад

Sehr gutes Video, David! 👍Die meisten Videos zu Interfaces hören nämlich da auf, wo du mit der Entkopplung anfängst.

@DavidTielke Год назад

Hey Frank, vielen Dank - freut mich sehr, dass Dir das Video gefällt :) Gruß David

@bartolo9294 3 года назад

Abo ist raus, danke für deine Arbeit :D

@DavidTielke 2 года назад

Danke, Gerne! Gruß David

@antonioparisi4311 Год назад

Am Montag auf der DDC2022-Köln kam ich beim Thema Entkoppelung im Workshop Softwarearchitektur leider nicht mehr mit und musste quasi nachsitzen, d.h. erst mit diesem Video kam dann der ersehnte Aha-Effekt😀 Top Video in angemessener Sprechgeschwindigkeit, im Vergleich zum Workshop👍

@DavidTielke Год назад

Hallo Antonia, das tut mir leid und freut mich zugleich. Leider ist es bei den 1-tägigen Workshops immer etwas doof. Bei 6-8 Teilnehmern erkennt man welches Tempo angemessen ist und wer was verstanden hat, bei den 36 Leuten war es leider nicht anders möglich. Sorry - aber hier hat es ja dann geklappt :) Gruß David

@alexanderbehling4680 2 года назад

Vielen Dank für dieses super Video. Ich hoffe ich habe das richtig verstanden. Damit man DI überhaupt nutzen kann, müssen in den Objekten die man darüber injiziert keine statischen Methoden vorhanden sein. Wenn dem so ist, wurde mir während der Ausbildung die OOP falsch gelehrt. Mir wurde der Leitsatz eingebläut, wenn die Methode keine Abhängigkeit zu den Klasseneigenschaften hat, mach diese statisch.

@jenseichberg3426 2 года назад

super interesantes Video !!

@DavidTielke 2 года назад

Hey Jens, vielen dank für Dein Feedback, schön das Dir das Video gefallen hat :) Gruß David

@donmarten 4 года назад

Danke :)

@DavidTielke 4 года назад

Gerne :)

@marcoexe11 3 года назад

Besser hätte man das nicht erklären können. Leite ich auf jeden Fall meinem Lehrer weiter! =)

@DavidTielke 3 года назад

Hey Marco, vielen Dank - ich hoffe es hilft Ihm weiter ;) Gruß David

@cueware9277 4 года назад

1a erklärt!!! Vielen Dank!!! Die Struktur und der Aufbau des Videos finde ich perfekt umgesetzt. Ich habe jetzt einige Interfaces zu schreiben :) In deiner Buchhaltungssoftware hast du vieles in Klassenbibliotheken strukturiert (Billing, Billing.Contracts, Billing.Test usw.) In die Contracts kommen dann wohl nur die Interfaces rein? Jede Klassenbibliothek erzeugt dann aber auch eine .dll. Wenn du jetzt nur wenige Interfaces schreibst ist die .dll ja ziemlich klein. Macht es da nicht mehr Sinn das direkt in die Urprungsbibliothek zu schreiben und dort einen Ordner Contracts zu erzeugen? Was spricht dagegen? Oder ist das einfach nur Geschmacksache?

@garretton 4 года назад

Hey Cue Ware, wenn andere Projekte wie z.b. das ReceiptManagement nun Klassen des Billing Projekts verwenden möchten, wird nicht das Billing in den Dependencies des ReceiptManagement referenziert sondern immer das Contracts Projekt. Dadurch kommst du gar nicht erst in Versuchung konkrete Klassen irgendwo zu verwenden. Du wirst damit des weiteren gezwungen die Interfaces im ReceiptManagement zu verwenden, um eben stets eine Dependency Injection zu haben. In deinem Fuck-Up-Point "registrierst" du dann diese Interfaces zu der jeweiligen konkreten Klasse. Das Projekt, in dem dann dieser Fuck-Up-Point liegt, hat dann leider sehr viele Dependecies auf alle möglichen Projekte. Diesen Nachteil musste ich in meiner Anwendung bisher in Kauf nehmen und habe noch keine Lösung gefunden. Trotzdem ist es dadurch sehr einfach Implementierungen zentral an einer Stelle auszutauschen. ich hoffe ich konnte dir helfen. Bei weiteren Fragen stehe ich gerne zur Verfügung. :) Falls ich hier etwas falsch erklärt habe oder etwas fehlt, kann mich David gerne korrigieren bzw. Wissen ergänzen. :)

@DavidTielke 4 года назад

Hallo, diese Art der Implementierung ist eine spezielle Architektur, die Composite Component Architecture - dazu findest du massenweise Artikel von mir bei der dotnetpro. In diesen Contract-Assemblies liegen Schnittstellen, Datenklasse, Callbacks, Exceptions und Messages (falls Du einen EventBroker nutzt). Damit entkoppelst Du deine Komponenten genau so, wie du mit Schnittstellen auf der Klassenebene entkoppelst. Aber dazu gibt es bald bestimmt mal ein Video :) Was die Größe der Projekte angeht: Es ist richtig, dass diese am Anfang sehr klein sind aber im Laufe des Projektes wachsen diese An, je mehr du von der Aufgabe der Komponente implementierst. Wenn Du eine Schnittstelle zu einer Klasse erzeugst, hat diese zu Beginn ja meist auch wenige Methoden und wächst erst im Laufe der Zeit an - genau so ist es bei diesen Contract-Assemblies auch. Gruß David

@DavidTielke 4 года назад

Vollkommen richtige Aspekte die Du anführst, zusammen mit meiner Antwort ergibt sich ein vollständiges Bild :) Was das Projekt mit dem Fuck-Up-Point angeht, dazu gibt es keine Lösung: im Fuck-Up-Point befinden sich alle Erzeugungsabhängigkeiten. Diese sind für die Anwendung zwingend erforderlich, mit IOC schieben wir sie aber aus der gesamten Anwendung an einen einzigen Punkt zusammen - eben der Fuck-Up-Point, welcher später wie von Dir richtig geschrieben in ein Projekt ausgelagert wird. Dieses Projekt hat maximal viele Abhängigkeiten, ist nicht testbar, wiederverwendbar, austauschbar oder sonst irgendetwas. Aber genau das ist der Trick, dieses Projekt nimmt die "Schuld" von allen anderen Projekten auf sich und ist aus Softwarequalitätsperspektive eine Katastrophe - aber dafür sich alle anderen Projekte 1a entkoppelt :) Gruß David

@cueware9277 4 года назад

@@garretton vielen Dank für diene Antwort... jetzt habe ich es verstanden :)

@cueware9277 4 года назад

@@DavidTielke Hallo David, in deinen Videos hattes du auch davon etwas erwähnt... ich lese mich mal da ein. Danke :)

@justinstevenferdinand1989 3 года назад

Ich stoße erst jetzt auf dieses Video und habe mich zuvor nicht so intensiv mit der Objekt Orientierung beschäftigt und habe dank dieses Videos das Prinzip verstanden. Dennoch bleibt bei mir noch zwei Fragen offen, nämlich bei Hibernate, Spring JPA o.ä. Frameworks erstellt man ja Repositorys um auf bestimmte Datenzugreifen und Injected diese (in Java über Autowired z.B.), sollte man diese jetzt auch nochmal nach der Methodik behandeln oder reicht das jetzt schon aus? (finde das nämlich bisschen verwirrend gerade) Dasselbe frage ich mich bei selbstgeschriebenen Klassen(welche man zu einem Service, Component o.ä. macht in Java) die man über Autowired/Inject o.ä. aufruft in der Klasse Manager, ist es da ausreichend, wenn man so arbeitet oder sollte man da dasselbe machen? Ich arbeite in Java mit Spring eigentlich nurnoch mit diesen Services die ich nurnoch über Autowired oder Inject in der Klasse aufrufe und Frage mich halt ob ich damit irgendeine Regel verletze oder wie ich da umgehen sollte, ich hoffe du kannst mir bei meiner Frage helfen & ich hoffe du siehst die, obwohl das Video schon relativ alt ist :)

@sabiplaypuzzles7332 Год назад

Hi David, ich hoffe, dass du die Kommentare in solchen alten Videos noch liest. Ich habe da mal eine allgemeine Frage zu Schnittstellen: Wieso nennt man das Schlüsselwort "interface"? Wenn ich an das Wort Interface denke, dann denke ich zB an öffentliche Methoden, Felder bzw. properties. Es ist von außen gesehen eine Kommunikationsschnittstelle, ein Zugriffspunkt. Interfaces bei der OOP sind für mich eher gesehen Contracts, also eher im Sinne von Normen/Standards, Verträge eben. Wieso hat man diese dann eben nicht contracts, standards oder norm genannt? Ähnlich geht es mir mit dem Schlüsselwort "static". Das Wort "classmember" oder "classonly" wäre doch passender. Wobei "static" sinngemäß noch nachvollziehbar ist, bei "interface" hingegen hatte ich schon immer meine Probleme.

@benediktzink4731 5 месяцев назад

Also alles gut .... ich habe es auch so verstanden ;) Aber (konstruktive Kritik) Wieso das Codebeispiel nicht dann auch am genannten Beispiel ausrichten ;) Bier und Chips(e) ? Sonst wirklich top !!!

@tirashop5685 2 года назад

#fragDavid Dependency Injection ist echt ein Cooles ding. Ich möchte Ihnen fragen. Wie gehen Sie mit der Fehlermeldung "Circular Verweis" um? zum Beispiel IA => IB => IA (interface A ruft interface B und die interface B ruft wieder die A) . LG aus Bremen

@sral8769 10 месяцев назад

Ich habe noch nie eine Projektmappe mit so vielen Projekten gesehen ... ich denke das ist etwas zu extrem, gerade weil zur Compilezeit da etwas sehr viele DLL Dateien rauskommen und zur Laufzeit geladen werden müssen. Man kann solche Strukturen auch innerhalb eines Projekts machen dann hat man aber nicht mehr so leicht überprüfen ob ein Entwickler heimlich/versehentlich eine Abhängigkeit eingefügt hat die es nicht geben soll

@hendrikj.382 2 года назад

Sehr gutes Video! Ich frage mich aber noch wie ich mit Objekten/Klassen umgehe, die von einzelnen Komponenten geteilt werden. Beispiel: Ich habe die Komponenten Komp1, Komp2 und Komp3. In Komp1 existiert sowohl die Definition für Komp2 (also IKomp1) als auch für Komp3 (also IKomp3) , das heißt Komp2 und Komp3 werden in Komp1 injiziert. In Komp2 und Komp3 existiert jeweils die Methode create, die ein Objekt einer Klasse (Result) zurück gibt und als Parameter ein Objekt der Klasse Param entgegen nimmt. Theoretisch müssten die Klassen Result und Param jetzt in allen drei Komponenten bekannt sein, was aber zu einer starken Kopplung führen würde. Daher frage ich mich; ob die Klassen Result und Param in einen Contract sollten, der von allen drei Komponenten implementiert wird? Und was würde man machen wenn so ein Objekt durch mehr als zwei Komponenten gereicht werden müsste? Bei dem Person Beispiel muss das Objekt vom Typ Person ja auch aus dem Repo in den Manager und dann in die UI. VG!

@alexanderbehling4680 2 года назад

Genau. Mehr dazu in diesem Video ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-0OPbSikgqtU.html

@sral8769 10 месяцев назад

Man könnte statt einem interface auch eine abstrakte (basis) Klasse machen :)

@MaKi-dr6jk 7 месяцев назад

Tolles Video aber kameratechnisch ausbaufähig

@bernhardd626 Год назад

Tut mir leid, aber was mir am meisten im Gedächtnis geblieben ist, ist der Plural von Chips: Chipse. Das hat sich wohl schon jeder mal gefragt😅

@DavidTielke Год назад

Hehe, wenn das hängen geblieben ist, muss ich dringend meine Videokonzepte überarbeiten :) Lg

@bernhardd626 Год назад

@@DavidTielke War natürlich nur Spaß ;-) Deine Videos sind echt super, ich habe sie gleich einem Kollegen gezeigt. Was mich auch ziemlich beeindruckt, wie du manchmal scheinbar ohne Unterbrechung erzählst. Das sieht manchmal fast wie ein One-Shot-Video aus oder zumindest große Teile. Oder ist die Technik inzwischen so gut, dass man die Schnitte nicht mehr erkennt? Du erklärst auch auf eine "wachhaltende" Art. Man wird nicht müde oder gelangweilt zuzuhören. Toll! Ich wundere mich, warum du nicht noch mehr Aufrufe hast. Aber wenn ich dich hier gerade schon an der "Strippe" habe: eine Sache bei dir bzw. deiner Einstellung geht nicht in meinen Kopf. Was mich als "langgedienten" (erfahren will ich gar nicht sagen) Entwickler schon immer fasziniert hat, sind die Ursachen dafür, warum Software-Projekte irgendwann unwartbar werden (und Millionenkosten verursachen). Das habe ich schon so oft beobachtet und davon gehört und ich meine dafür zwei Gründe auszumachen: ein Grund ist das, weswegen du hier die Videos machst. Aber der andere Grund, IMHO, ist vielleicht noch bedeutender und da sehe ich dich komplett auf der falschen Seite. Da würde mich deine Meinung dazu wirklich brennend interessieren, denn entweder verstehe ich was falsch oder ich bin doof oder alle anderen 🙂 Wenn es für dich ok ist, würde ich dich dazu mal befragen, muss ich aber sorgfältig formulieren. (fyi: ich habe auch Informatik studiert, also vom Fach, aber nicht deine vielseitige Erfahrung, auch wenn ich älter bin)

@paulfrischknecht3999 3 года назад

software ist wissen

@alexanderbehling4680 2 года назад

Absolut. Nur nützt das beste Wissen nichts, wenn es nicht ständig auf Aktualität geprüft und ggf. durch neues Wissen ergänzt / ersetzt wird.

@JanBebendorf 3 года назад

Die Analogie ist nicht so ganz richtig. Der Chef sagt nämlich ohne DI nur hol Bier und Chips und er bestimmt nicht, wo du diese holst, da du nur LIDL kennst. Mit DI ist es dir egal in welchem Laden du einkaufst, denn der Chef sagt dir wo du einkaufen sollst. Ich weiß auch nicht, ob reine Constructor Injection so eine gute Idee ist, da ohne DI Container zwar die Logik entkoppelt wird, Strukturveränderungen auf Grund der nun entstanden Abhängigkeiten durch die ganze Anwendungsstruktur nach oben jedoch weiterhin eingeschränkt sind. Wenn ich z.B. eine Abhängigkeit komplett eliminieren will, muss ich sie im schlimmsten Fall bis zum Stamm wieder aus den Konstruktoren entfernen (insofern sie nicht in einem anderen Zweig noch in Verwendung ist). Mal ganz abgesehen davon will ich die Konstruktoren bei tiefen Strukturen mit vielen Abhängigkeiten, die auf Anwendungsebene instanziert werden, nicht sehen. Wir haben in unseren Projekten z.B. auch gern mal Logik die teilweise auf bis zu 10 Repositories und nebenbei noch auf verschiedene API's zugreifen muss (ich weiß bei so vielen Abhängigkeiten sollte man eig. die Softwarearchitektur überdenken, aber manches lässt sich nicht verkleinern).

@paulfrischknecht3999 3 года назад

um sich noch besser zu entkoppeln sollte man imo nur auf asynchrone, Promise oder Future basierte interfaces zugreifen. Dann gehe ich nicht davon aus, dass die Antwort synchron erzeugt wird