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

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

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

50% 1

Das Dependency Inversion Principle ist Bestandteil der SOLID Principles (SOLID Prinzipien) zur Verbesserung der Software Architektur, welche von dem Cleancoder Robert C. Martin alias Uncle Bob Anfang der 2000er Jahre definiert wurden. Dabei ist das Dependency Inversion Principle (kurz DIP) das wichtigste unter den Entwurfsprinzipien und ist für die Entkopplung von Modulen zuständig. In dieser Episode schauen wir uns das Dependency Inversion Principle der SOLID Principles genauer an, schauen was das mit Clean Code bzw. Clean Coder zu tun hat und warum die Definition von Robert C. Martin alias Uncle Bob nicht so leicht zu verstehen ist. Viel Spaß mit dieser Serie zu den SOLID Principles.
Das erwähnte Buch: Agile Principles, Patterns, and Practices in C# - amzn.to/34wSkwj
Diese Episode zu Dependency Inversion Principle ist ein Teil einer ganzen Serie zu den SOLID Principles:
- Playlist: • SOLID Principles von R...
- Teil 1: Single Responsiblity Principle (SRP) - • Single Responsibility ...
- Teil 2: Open Closed Principle (OCP) - • Open Closed Principle ...
- Teil 3: Liskov Substitution Principle (LSP) - • Liskov Substitution Pr...
- Teil 4: Interface Segregation Principle (ISP) - • Interface Segregation ...
- Teil 5: Dependency Inversion Principle (DIP) - • Dependency Inversion P...
▬ Ü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 ▬▬▬▬▬▬▬▬▬▬▬▬
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
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Наука

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

7 окт 2020

Ссылка:

Скачать:

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

Добавить в:

Мой плейлист

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

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

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

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 3 года назад

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 2 года назад

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

@parryhotter18 3 месяца назад

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 :-)

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

Das ist unglaublich gut erklärt. Abo haste

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

Merci :)

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

Sehr gelungen! Danke für den Content

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

Vielen Dank, sehr gerne!

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

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 3 года назад

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 3 года назад

@@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 3 года назад

@@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 2 года назад

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.

@user-tn5jk9ie5l 2 года назад

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?