DRY-Code ohne Bezug, aber nahezu identisch

Ich habe einen Code, der fast identisch ist, aber absolut unterschiedliche Typen ohne Vererbung zwischen ihnen für die Hauptvariable verwendet. Insbesondere schreibe ich einen Analysator mit Roslyn 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, weil der Code dasselbe tut, ihn so trocken wie möglich halten soll, indem ich ihn so wenig wie möglich in separate (aber mit Ausnahme des Typs identische) Methoden aufspalte oder ihn vollständig trenne, weil die beiden Methoden identisch sind Nicht verwandte und zukünftige Änderungen könnten eine Version zur Änderung zwingen, 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 TAttributeSyntaxParameter hat, der die meiste Arbeit leistet. Schreiben Sie dann abgeleitete Klassen mit dem Minimum an Daten, die einen bestimmten Typ benötigen.

Du machst DRY nicht, weil jemand es in ein Buch geschrieben hat, das es gut macht. Du machst DRY, weil es tatsächlich greifbare Vorteile hat.

Speziell aus dieser Frage:

Wenn Sie sich wiederholen, können Sie Wartbarkeitsprobleme erstellen. Wenn doStuff1-3 alle ä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 einzufügen.

Allerdings wird DRY von geschickten Programmierern oft als extrem empfunden. Um sich nicht zu wiederholen, müssen Sie manchmal 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 durch das Umgestalten nicht wiederholt werden, unnatürlichen Code schreiben oder clevere Codierungs-Backflips ausführen müssen, durch die Ihr Team Sie anstarrt, ist es möglicherweise in Ordnung, sich selbst zu wiederholen. Ich habe mich nach hinten gebeugt, um mich nicht ein paarmal unnatürlich zu wiederholen, und das Endprodukt bereut.

Also denke im Grunde nicht "oh man, dieser Code ist ziemlich ähnlich, vielleicht sollte ich mich überarbeiten, um mich nicht zu wiederholen". Denken Sie, "macht das Umgestalten, um diese Codebasis wiederzuverwenden, gemeinsame Elemente den Code wartbarer oder weniger wartbar ?" Wählen Sie dann den, der die Wartung erleichtert.

Angesichts der SRP und der Tatsache, dass Sie nur versuchen, kleine, flexible Klassen zu haben, ist es möglicherweise sinnvoll, Ihren Code aus diesem Grund zu analysieren und Verhaltensmerkmale zu zerlegen, in die generische Typen (Sie sagten, dass sie von Typ verschieden sind) verwendet werden kleine Klassen. Dann werden Sie feststellen, dass einige dieser Klassen tatsächlich völlig identisch sind (nicht nur größtenteils identisch), und dann können Sie ein Toolkit erstellen, falls Sie es hinzufügen möchten Microsoft.CodeAnalysis.CPlusPlus.Syntax.AttributeSyntax.