it-swarm.com.de

DRY nicht verwandter, aber nahezu identischer Code

Ich habe einen Code, der nahezu identisch ist, aber für die Hauptvariable absolut unterschiedliche Typen ohne Vererbung verwendet. Insbesondere schreibe ich mit Roslyn einen Analysator für C # und VB.NET mit den folgenden Typen:

Microsoft.CodeAnalysis.CSharp.Syntax.AttributeSyntax Microsoft.CodeAnalysis.VisualBasic.Syntax.AttributeSyntax

Ich frage mich, ob ich, da der Code dasselbe tut, ihn als DRY wie möglich) beibehalten und so wenig wie möglich in separate (aber vom Typ identische) Methoden aufteilen sollte. oder vollständig trennen, weil die beiden Methoden nicht miteinander verbunden sind und zukünftige Änderungen eine Version zur Änderung zwingen könnten, aber nicht die andere (obwohl dies unwahrscheinlich ist)?

Bearbeiten : Etwa ein Jahr später stieß ich auf dasselbe Problem, und das Roslyn-Team half mir bei der Lösung: Schreiben Sie eine Basisklasse, die Generika verwendet und einen TAttributeSyntax -Parameter hat, der am meisten funktioniert der Arbeit. Schreiben Sie dann abgeleitete Klassen mit dem Minimum an Daten, die einen bestimmten Typ benötigen.

34
user113093

Sie tun nicht DRY, weil jemand es irgendwo in ein Buch geschrieben hat, wo es gut ist, Sie tun DRY, weil es tatsächlich greifbar) hat Vorteile.

Speziell aus dieser Frage:

Wenn Sie sich wiederholen, können Sie Wartbarkeitsprobleme verursachen. Wenn doStuff1-3 alle einen ähnlich strukturierten Code haben und Sie ein Problem in einem beheben, können Sie leicht vergessen, das Problem an anderen Stellen zu beheben. Wenn Sie einen neuen Fall hinzufügen müssen, können Sie einfach verschiedene Parameter an eine Funktion übergeben, anstatt sie überall zu kopieren.

DRY wird jedoch häufig von cleveren Programmierern auf die Spitze getrieben. Manchmal müssen Sie Abstraktionen erstellen, die so stumpf sind, dass Ihre Teamkollegen ihnen nicht folgen können. Manchmal ist die Struktur zweier Dinge nur vage ähnlich, aber unterschiedlich genug. Wenn doStuff1-4 so unterschiedlich sind, dass Sie unnatürlichen Code schreiben oder sich cleveren Codierungs-Backflips unterziehen müssen, die Ihr Team dazu bringen, Sie anzustarren, ist es möglicherweise in Ordnung, dies zu wiederholen Ich habe mich nach hinten gebeugt, um mich nicht ein paar Mal auf unnatürliche Weise zu wiederholen, und das Endprodukt bereut.

Denken Sie also im Grunde nicht "Oh Mann, dieser Code ist ziemlich ähnlich, vielleicht sollte ich mich umgestalten, um mich nicht zu wiederholen". Denken Sie: "Macht Refactoring, um diese Codebasis zur Wiederverwendung allgemeiner Elemente zu machen, den Code wartbarer Oder weniger wartbar?" Wählen Sie dann die aus, die die Wartung erleichtert.


Angesichts von SRP und dem Versuch, generell kleine, flexible Klassen zu haben, kann es sinnvoll sein, Ihren Code auf diesen Grund zu analysieren, zerlegen Sie Verhaltensmerkmale, die generische Typen verwenden (Sie sagten, dass sie mit Ausnahme des Typs identisch sind), in kleine Klassen. Dann werden Sie feststellen, dass einige dieser Klassen tatsächlich völlig identisch (nicht nur größtenteils identisch) sind, und dann können Sie ein Toolkit erstellen, falls Sie Microsoft.CodeAnalysis.CPlusPlus.Syntax.AttributeSyntax Hinzufügen möchten. .

110
durron597