In dieser Folge von „Der Macht der Kraft“ sprechen wir über die Erweiterbarkeit und konzentrieren uns besonders auf die Solid-Prinzipien. Wir diskutieren vier dieser Prinzipien und befassen uns auch mit dem Konzept der Separation of Concerns. Separation of Concerns bedeutet, dass wir unsere Anwendung in Module aufteilen und Verantwortlichkeiten klar trennen, um eine klare Struktur und Encapsulation zu erreichen. Wir arbeiten dabei auf einer höheren Abstraktionsebene, bei der es darum geht, den Code zu organisieren und nicht darum, wie er geschrieben wird. Durch die Separation of Concerns können wir Module separat deployen und verwalten und sie auch erweitern oder ersetzen. Dies trägt zur Erweiterbarkeit und Wartbarkeit bei. Ein einfaches Beispiel ist die Aufteilung von HTML, CSS und JavaScript in separate Dateien für eine Web-Anwendung. Eine weitere gute Anwendung von Separation of Concerns ist die Auslagerung von Datenbankzugriffen in ein separates Package. Ein weiteres Beispiel ist die Trennung von Kunden- und Bestellkonzepten in einem Online-Shop. Es ist wichtig, diese Konzepte getrennt zu behandeln und nicht in einer Klasse zu vermischen.

Indem wir das Prinzip der Separation of Concerns anwenden, wird unsere Anwendung erweiterbarer. Durch eine klare Trennung der Verantwortlichkeiten schaffen wir ein sauberes System. Dadurch können wir neue Funktionen problemlos hinzufügen, ohne den bestehenden Code stark zu verändern. In dieser Episode des Podcasts widmen wir uns den Solid-Prinzipien, insbesondere dem Single Responsibility Principle. Dieses besagt, dass eine Klasse oder ein System nur einen Grund haben sollte, geändert zu werden. Eine Klasse sollte sich nur um eine Verantwortlichkeit kümmern und nicht um verschiedene Aufgaben gleichzeitig. Es kann schwierig sein, eine Verantwortlichkeit genau zu definieren, aber im Allgemeinen bedeutet es, dass es nur einen Grund gibt, eine Klasse zu ändern. In unserem täglichen Arbeitsprozess achten wir darauf, ob eine Klasse zu viele Verantwortlichkeiten hat und versuchen, diese sinnvoll aufzuteilen. Es ist wichtig, dass wir im Team ein gemeinsames Verständnis für die Verantwortlichkeiten haben und klar ist, welche Aufgaben eine Klasse erfüllen soll. Durch die Anwendung des Single Responsibility Principle reduziert sich die Diskussion darüber, wo bestimmte Funktionen hingehören. Es ist auch wichtig, die Benennung von Klassen zu beachten, um klarzustellen, welche Verantwortlichkeiten sie haben. Zum Beispiel kann die Verwendung des Namens „Manager“ oft zu einer Überladung der Klasse führen. Daher ist es wichtig, sorgfältig über die Bezeichnung von Klassen nachzudenken.

Es ist wichtig, unsere Klassen und Funktionen so zu gestalten, dass sie offen für Erweiterungen, aber geschlossen für Veränderungen sind. Das bedeutet, dass wir neue Funktionen als zusätzlichen Code hinzufügen sollten, anstatt den bestehenden Code zu manipulieren. Anstatt eine große komplexe Methode zu haben, die jeden Fall abdeckt, sollten wir Methoden lieber aufteilen. Ein Beispiel dafür ist die Vererbung, bei der eine Basisklasse grundlegende Funktionalitäten enthält und dann eine neue Klasse davon abgeleitet wird, um spezifisches Verhalten hinzuzufügen. Es funktioniert auch mit Komposition, indem wir verschiedene Klassen verwenden, anstatt alles in einer großen Klasse zu haben. Das Open-Closed-Prinzip ist ein interessantes Konzept, das uns hilft, den Code lesbarer, änderbarer und erweiterbarer zu machen.

Es mag zunächst seltsam erscheinen, gleichzeitig offen und geschlossen zu sein. Die Bootstüren sind offen und geschlossen, aber irgendwie auch beides nicht. Es ist wichtig, zu verstehen, wie wir uns am Arbeitsplatz positionieren und was das für uns bedeutet. Das Open-Close-Principle ermöglicht es uns, den bestehenden Code beizubehalten, ohne ihn zu verändern, um neue Funktionen hinzuzufügen. Dadurch bleibt die bisherige Funktionalität erhalten und wir können sicherstellen, dass keine Fehler eingeführt werden. Wir erweitern unsere Einheiten, anstatt sie zu verändern, und stellen sicher, dass die Schnittstellen stabil sind, um mögliche Änderungen zu minimieren. Das Interface Segregation Principle geht darum, Interfaces möglichst klein und fokussiert zu gestalten und nur die benötigten Methoden nach außen zu veröffentlichen. Es ist wichtig, dass ein Nutzer nicht gezwungen ist, unnötige Methoden zu implementieren. Es geht also darum, die Verantwortlichkeiten klar zu definieren und Interfaces auf die Aufgaben zu beschränken, für die sie benötigt werden.

Wir müssen sicherstellen, dass unsere High-Level-Module nicht von Low-Level-Modulen abhängig sind. Stattdessen sollten beide von Abstraktionen abhängig sein. Dies erreichen wir durch das Dependency Inversion Principle. Anstatt von konkreten Implementierungen abhängig zu sein, sollten wir Interfaces verwenden. Dadurch können wir Schnittstellen definieren, die auf verschiedene Arten implementiert werden können, je nach Bedarf. Auf diese Weise reduzieren wir die Kopplung in unserer Anwendung.

Wir haben uns die Solid-Prinzipien angesehen und über das Separation of Concerns gesprochen. Das Dependency Inversion Principle ermöglicht es uns, die Abhängigkeiten von Klassen durch die Verwendung von Schnittstellen zu verringern. Dadurch wird die Kopplung zwischen den Klassen reduziert und Änderungen werden einfacher. Es ist faszinierend, dass dieses Prinzip auf verschiedenen Ebenen angewendet werden kann, sowohl auf System- als auch auf Klassenebene. Im nächsten Podcast werden wir über kontinuierliche Verbesserung sprechen. Abonniere unseren Podcast und empfehle die Folge weiter. Bis zum nächsten Mal!

00:00:00.058 Einleitung und Begrüßung zur Folge
00:03:05.955 Diskussion über Separation of Concerns und DDD
00:06:12.338 Beispiel: Trennung von Kunden und Bestellungen im Online-Shop
00:07:58.938 Einleitung zu den Solid-Prinzipien und Ankündigung der Themen
00:10:08.395 Kein klares Regelwerk, sondern Gefühl für zu viel Verantwortung
00:12:00.402 Die Wahl des Klassennamens und Überladung der Funktionen
00:20:29.273 Anpassung der Tests bei sich verändernder Funktionalität
00:22:27.996 Verwendung von getrennten Schnittstellen für Erweiterungen
00:23:20.883 Single Responsibility for Interfaces
00:25:14.933 Splitting Interfaces based on Usage
00:30:03.329 Dependency Inversion: Ein Prinzip zum Entkoppeln von Modulen
00:31:32.715 Dependency Inversion Principle zur Reduzierung der Kopplung
00:35:27.627 Anwendung des Dependency Inversion Principle auf verschiedenen Flughöhen

Transkript hier einfügen