Dependency Inversion Principle (DIP) der SOLID Principles von Uncle Bob

[@mplaimer]

Hallo David. Dank dir für diese tolle Videoserie über die SOLID Prinzipien. Erklärungen waren sehr verständlich und generell die ganze Gestaltung der Videos echt super gemacht. Gut strukturiert. Top! Danke nochmal dafür und dass du dein Wissen mit der Community teilst.

[@DavidTielke]

Hey Markus, vielen Dank - schön das die Art, Struktur und die Beispiele so gut angekommen sind - mir lag es sehr am Herzen dazu mal gescheite Videos zu machen, weil ich finde das es dazu auf YT noch nicht viel gescheites gibt. Sehr gerne! Gruß David

[@eikeimnetz]

Bin wirklich sehr dankbar für die schöne Serie von sauberem programmieren. Bleib bitte dran!

[@doomslayer_666_]

Das ist unglaublich gut erklärt. Abo haste

[@DavidTielke]

Merci :)

[@parryhotter18]

Sehr gut erklärt, wie immer, vielen Dank. Zu der besch... Erklärung: Die "Schichten" ergeben sich von alleine, wenn man Top->Down vorgeht, bzw vorgehen kann (wenn die "unteren" Module nicht schon vorgegeben sind.) Dann benötigt der PL, aufgrund der Anforderungen an ihn selber, einen Satz von Funktionen vom ML. Diese Funktionen bilden das PSI. Das kann man daher gut auf der Ebene des PL zeichnen, d.h. auf der Ebene des Anforderers. Man könnte es auch zwischen PL und ML zeichnen. Bescheuert fände ich keine Variante :-)

[@ChristophLoacker]

21:54 - 22:15 --> Das macht schon Sinn. Klassische 3 Layer Architektur mit UI --> BL --> DB. Drehe die Abhängigkeiten zwischen BL und DB um und du hast ein BL Layer ohne jegliche Abhängigkeiten.

[@DavidTielke]

Hallo Christoph, ja in der Darstellung ist das richtig, aber in der Praxis ist es unsinnig weil der Kontrakt ja Bestandteil der jeweils anderen Schicht ist und dort überhaupt nichts zu suchen hat. Das würde dann ja bedeuten, dass ich den DLnicht mehr ohne den BL wiederverwenden könnte und das ist die häufigste Art der Wiederverwendung in einer Mehrschichtenarchitektur, die ich bis heute festgestellt habe. Gruß David

[@danielsteininger6753]

@@DavidTielke Hallo. Ansich ein schönes Video aber ich stimme allerdings auch eher dem Christop zu. Der Grund warum die Abhängigkeit umgedreht wurde, besteht ja darin die Unabhänigkeit von BL zu bekommen. Wenn jetzt BL anstatt DL das Interface definiert, kann DL das zwar implementieren, es muss aber von DL nicht das einzige implementierte Interface sein. Umgangssprachlich würde ich es als WunschInterface von BL bezeichnen. Aus deiner Betrachtung wäre es eher ein AnbietInterface von DL. PS. Toller Kanal.

[@marcusmann3684]

@@danielsteininger6753 "WunschInterface" ist ein schönes Wort und damit gehört es (m.E. natürlicherweise) auch in die obere Schicht. Eigentlich ist ein Interface ja immer ein Wunsch, wenn ich im Januar ein Interface definiere und eine erste Implementation schreibe dann *muss* sich die nächste Implementation im Juli (nach Januar) daran halten (wenn man mal von Erweiterungen absieht). Ich glaube allerdings auch das es zzt noch *persönliche* Defnitionssache ist, mit der Zeit wird sich eine Standard-Defnition (dafür wo es hingehört) herausbilden. Edit: Nach Lesen des Wikipedia-Artikels ist es für mich jetzt klar dass das Interface zur oberen Schicht gehört; wenn das Interface zur unteren Schicht gehören würde hätten wir wieder einen Pfeil von der oberen zur unteren Schicht der *auf das Interface* zeigt.

[@PeterEichhorn]

Ich stimme hier auch zu, nach allen Videos die ich zu Clean Architecture gesehen habe von Uncle Bob und Jason Taylor, geht es darum den Business Layer unabhängig von allem IO zu machen. Der BL definiert alle Schnittstellen nach außen. Dir ist egal wohin gespeichert wird und auch welches Gerät deine Daten ggf. anzeigt. Damit kannst du den BL wunderbar testen. Die "normale alte" Herangehensweise hat die DB immer in den Vordergrund gestellt, weswegen sich oft Datenbank Klassen bis in die GUI gezogen haben, wenn auch gemappt. Das ist auf den ersten Blick zwar nicht schlimm, aber du hast eben Code der quasi der DB entspricht und wenn du da was umbaust, passen deine ganzen Domain Objekte nicht mehr. Dabei sollte doch die Domain vorgeben welche Daten relevant sind und nicht irgend welche Tabellen.

[@cong6678]

Sehr gelungen! Danke für den Content

[@DavidTielke]

Vielen Dank, sehr gerne!

[@exti1000]

Lässt sich das DIP in etwa so Zusammenfassen: Mein High-Level Modul hält einen Basisklassenzeiger auf die Interfaces der entsprechenden Low-Level Module die es nutzen will. Die Flexibilität ist dadurch gegeben dass mit dem Basisklassenzeiger beliebige Instanzen eines konkreten Low-Level Moduls getauscht werden können ohne den Code im Highlevel Modul anzupassen.

[@user-tn5jk9ie5l]

Hallo David, warum machst du nicht ein kleines Online-Workshop Anhang eines kleinen Beispielprojekt oder Bücher schreiben die von Anfänger bis Fortgeschrittene gehen das man diese Kaufen kann. So ähnlich wie du jetzt Anhang eines Codes zeigst. So kannst du anhand eines kleines vielleicht ausgedachtes Projektes viele Prinzipien den Einsteiger direkt übermitteln. Wie fange ich überhaupt an meine Idee umsetzen? Wo soll ich beginnen? Ich finde genial wie du es immer erklärst. Man kann süchtig danach werden. Danke noch mal für deine Videos 👍 Tatjana

[@BinGanzLieb]

Eine Frage. Durch DIP arbeitet man gegen Kontrakte und nicht gegen konkrete Klassen. Aber erzeugt man dadurch nicht eine Abhängigkeit zu Kontrakten? Was ist, wenn ich Kontrakte austauschen will?