DRY-Prinzip in C#: Warum Code-Duplizierung Ihrer Codebasis schadet - Erklärt von Derek Comartin

DRY-Prinzip definiert

Zu Beginn des Videos stellt Derek den Kontext dar, mit dem viele Entwickler konfrontiert sind: Sie haben es mit einem System zu tun, das nur schwer zu ändern ist - ein Wirrwarr aus sich wiederholendem Code und redundanter Logik.

Er führt das DRY-Prinzip in C# als Strategie zur Reduzierung von Codewiederholungen ein, warnt aber davor, dass es oft falsch interpretiert wird. Wie Derek bei 0:28 erklärt:

Wenn DRY erfolgreich angewendet wird, erfordert eine Änderung an einem einzelnen Element des Systems keine Änderung an anderen, logisch nicht verwandten Elementen."

Diese Unterscheidung ist entscheidend. Das DRY-Prinzip zielt nicht nur darauf ab, doppelten Code zu vermeiden, sondern auch die Trennung von Belangen und die angemessene Wiederverwendung von Code zu fördern - was zu wartbarem, trockenem Code führt, der einfacher zu testen und zu refaktorisieren ist.

Praktisches Beispiel: Umrechnung von Entfernungen

Um die Dinge greifbar zu machen, bietet Derek ein einfaches Beispiel in C# an. Er schreibt zwei Methoden:

• Schiffsentfernung

• Mautstrecke

Jedes Programm berechnet Entfernungen in Meilen und rechnet sie dann in Kilometer um, wobei in beiden Fällen die gleiche Logik verwendet wird. Dies ist eine klassische Codevervielfältigung.

Anstatt dasselbe Stück Code an mehreren Stellen zu haben, zeigt Derek, wie man die Konvertierungslogik in eine private Methode - MilesToKilometers() - extrahieren kann, eine einfache, aber effektive Methode zur Refaktorierung von Code für die Wiederverwendbarkeit.

Er illustriert dies anhand der typischen Struktur einer Konsolenanwendung: eine Klasse Program mit einer statischen void Main. Es handelt sich um die Art von Struktur, die viele Entwickler verwenden, wenn sie Logik testen oder mit einem neuen Benutzereingabeszenario experimentieren, wie z. B. public int age, string username, string password, etc.

Trocken vs. Überkopplung

Die Abstraktion der Logik in eine wiederverwendbare Methode oder eine separate Klasse klingt zwar ideal, doch Derek mahnt zur Vorsicht. Die übermäßige Verwendung von DRY, insbesondere für eine gesamte Anwendung, kann zu einem gefährlichen Grad an Kopplung führen.

Wenn Sie beispielsweise eine Konvertierungslogik in ein gemeinsames Dienstprogramm einfügen, das von mehreren Projekten verwendet wird, und später das Rundungsverhalten oder die Dezimalpräzision ändern, kann sich diese Änderung unerwartet auf viele Bereiche auswirken. Wie Derek es bei 2:31 ausdrückt:

"Erwarten die Kunden zwei Dezimalstellen? Was passiert, wenn wir es in Null ändern?"

Dies ist ein bereichsübergreifendes Anliegen - Logik, die von vielen Teilen des Systems wiederverwendet wird - und es zeigt das Risiko einer zu frühen Zentralisierung oder ohne klare Grenzen.

Dereks Ratschläge entsprechen dem Single Responsibility Principle und dem Dependency Inversion Principle, zwei weiteren SOLID-Prinzipien, die für die Anpassbarkeit und Modularität Ihres Codes entscheidend sind.

Code Bloat von DRY Gone Wrong

Ein weiteres Problem des DRY-Missbrauchs ist die Aufblähung des Codes - der Versuch, alles zu abstrahieren, führt zu aufgeblähten Utility-Klassen oder übermäßig generischen Methoden. Derek warnt davor, dass eine zu trockene Logik mehr schaden als nützen kann, insbesondere in großen Systemen, in denen Fehlerbehebungen in einem Bereich aufgrund gemeinsamer Abhängigkeiten andere Bereiche zerstören können.

Der Schlüssel liegt laut Derek darin, zu wissen, wann man Code nicht teilen sollte - vor allem, wenn dies zu eng gekoppelten Modulen führt. DRY ist keine Regel; es handelt sich um einen Leitfaden, der im Kontext verwendet werden muss.

DRY angewandt auf Entitäten: Ein Rezept für Komplexität

Derek erkennt eine verbreitete Tendenz bei Entwicklern: die Organisation von Systemen rund um Entitäten wie Truck, Order, Driver und Shipment. Es ist zwar verlockend, dieselbe Klasse oder dasselbe Objekt in verschiedenen Methoden wiederzuverwenden, doch führt dies häufig zu wiederholten Konzepten und unerwünschter Kopplung.

Er argumentiert, dass die Architektur von den Geschäftsfunktionen und nicht nur von den Datenstrukturen bestimmt werden sollte. Zum Beispiel ist das "Versenden einer Bestellung" ein anderes Anliegen als das "Abkoppeln eines Anhängers", auch wenn es sich um dieselben Entitäten handelt.

Bei 4:45 erklärt Derek:

Eine einzelne Entität in Ihrem System muss nicht zwangsläufig mehrere Konzepte repräsentieren

Dies verdeutlicht eine tiefere architektonische Erkenntnis: Entitäten mit demselben Namen (Fahrzeug, Anhänger) können in verschiedenen Arbeitsabläufen unterschiedliche Verantwortlichkeiten darstellen. Die austauschbare Verwendung der Begriffe führt zu Verwirrung und koppelt unverbundene Geschäftslogik eng miteinander.

DRY und Geschäftsfähigkeiten

Um dieses Problem zu lösen, stellt Derek die Vertical Slice Architecture (VSA) vor - ein Muster, das Anwendungen nach Geschäftsfunktionen statt nach Schichten strukturiert. Jedes "Slice" enthält alles, was für eine bestimmte Aktion oder einen Anwendungsfall benötigt wird - von der Anfrage bis zur Datenbank - gekapselt und in sich geschlossen.

Er betont, dass DRY-Code innerhalb eines Slices - also an einer einzigen Stelle - gut ist, aber die Anwendung von DRY über Slices hinweg kann zu verwickelten Abhängigkeiten führen. Bei 6:44 fügt er hinzu:

"Es geht nur darum, die Kopplung zu reduzieren, den Zusammenhalt zu erhöhen... eine Möglichkeit, das zu erreichen, besteht darin, Konzepte innerhalb einer Grenze nicht zu wiederholen."

Dieses grenzüberschreitende Denken gibt Ihnen Flexibilität. Möglicherweise haben Sie ein vollständiges Domänenmodell in einem Slice und nur ein leichtes Datenmodell in einem anderen. Es geht um die Bedürfnisse des Slice - ein pragmatischer Ansatz im Einklang mit der Philosophie von The Pragmatic Programmer.

Abschließende Gedanken

Derek schließt, indem er DRY als ein Werkzeug und nicht als ein Gesetz bezeichnet. Wie er es um 7:00 Uhr ausdrückt:

Es geht nur darum zu verstehen, wie man es anwendet. Wenn Sie die Software intensiv nutzen, haben Sie möglicherweise mehr Anschlussmöglichkeiten."

Bevor Sie also die Validierungslogik oder den Verbindungsstring extrahieren oder sich wiederholenden Code in eine separate Methode umwandeln, sollten Sie überlegen, ob Sie dadurch Ihre gesamte Codebasis wartbarer machen - oder nur schwieriger zu ändern.

Abschluss

Derek Comartins Aufschlüsselung des DRY-Prinzips in C# zeigt, wie eine scheinbar einfache Regel nach hinten losgehen kann, wenn sie nicht nuanciert angewendet wird. Indem er Code-Beispiele durchgeht, praktische Szenarien diskutiert und Software-Design-Prinzipien hervorhebt, zeigt er die notwendige Balance zwischen Wiederverwendbarkeit und Modularität auf.

Denken Sie daran, dass Sie Ihren Entwicklungsprozess erheblich verbessern können:

• Verwenden Sie DRY, um redundanten Code innerhalb eines klaren Rahmens zu refaktorisieren.

• Entitäten, die unterschiedlichen Geschäftszwecken dienen, sollten nicht entwässert werden.

• Achten Sie auf den Kontext, wenn Sie die Logik zentralisieren - insbesondere über mehrere Orte oder Projekte hinweg.

• Berücksichtigen Sie Unit-Tests und die Auswirkungen von Dependency Injection auf gemeinsam genutzten Code.

Wenn Sie diese Lektionen anwenden, werden Sie effizienteren, modularen und wartbaren C#-Code schreiben - und vermeiden, dass sich Ihre Codebasis in ein Rattennest aus doppelter Logik und verworrenen Abhängigkeiten verwandelt.

Sie können Derek Martins vollständiges Video für weitere Einblicke auf CodeOpinions YouTube-Kanal ansehen.