Ich muss Kompromisse eingehen: DRY oder Command-Query-Separation?

Ich habe kürzlich eine Methode überarbeitet, die sowohl ein Befehl als auch eine Abfragemethode war.

Nachdem ich es in eine Ein-Befehl-Methode und eine Abfragemethode unterteilt hatte, stellte ich fest, dass es jetzt mehrere Stellen im Code gibt, an denen ich den Befehl aufrufe und dann den Wert aus der Abfrage erhalte, was wie eine Verletzung des DRY-Prinzips erscheint.

Aber wenn ich diesen allgemeinen Code in eine Methode einbinden würde, wäre diese Methode sowohl ein Befehl als auch eine Abfrage. Ist das akzeptabel?

Es gibt immer Kompromisse zwischen widersprüchlichen Gestaltungsprinzipien. Der Weg, dies zu lösen, besteht darin, die zugrunde liegenden Gründe für die Prinzipien zu untersuchen. In diesem Fall ist es problematisch, eine Abfrage nicht ausführen zu können, ohne den Befehl auszuführen, aber es ist im Allgemeinen harmlos, einen Befehl nicht ausführen zu können, ohne die Abfrage auszuführen. Solange es eine Möglichkeit gibt, die Abfrage eigenständig auszuführen, sehe ich keinen Grund, das Abfrageergebnis nicht zum Befehl hinzuzufügen, insbesondere wenn Folgendes ausgeführt wird:

QueryResult command()
{
   // do command stuff
   return query();
}

Ich habe noch nie von Command-Query-Separation (CQS) gehört, aber es scheint, dass es sich um das Single Responsibility Principle (SRP) handelt, das besagt, dass eine Funktion / Klasse idealerweise für eine Sache und nur eine Sache verantwortlich sein sollte .

Wenn Ihr Befehlscode aus 20 Codezeilen besteht und der Abfragecode aus weiteren 30 Zeilen besteht und sich alle in einem Funktionskörper befinden, verstoßen Sie eindeutig gegen SRP, und ich würde auch von CQS ausgehen, und diese beiden Logikteile sollten voneinander getrennt werden .

Anhand Ihres hypothetischen Beispiels würde ich jedoch höchstwahrscheinlich eine Wrapper-Methode erstellen, die Ihren Befehl und Ihre Abfrage kombiniert, damit DRY an zahlreichen Stellen im Code nicht verletzt wird. Ich würde dies auch nicht als SRP- (und möglicherweise CQS-) Verletzung betrachten, da der Wrapper immer noch nur eine Verantwortung hat: Befehl mit einer Abfrage zu kombinieren und eine Abstraktion auf höherer Ebene zu erstellen, die einfacher zu konsumieren ist.

Ich denke, die Wrapper-Methode ist eine absolut akzeptable Lösung. Um dies zu veranschaulichen, gehen wir noch einen Schritt weiter. Was wäre, wenn Sie 2 Abfragen anstelle von 1 ausführen und dann eine darauf basierende Befehlsaktion ausführen müssten? Ihre 2 Codezeilen wären also 6 oder 8. Was wäre, wenn zwischen einer und der anderen eine Datenüberprüfung / -prüfung durchgeführt würde? Jetzt haben Sie also 15 Codezeilen. Würden Sie zweimal darüber nachdenken, einen Wrapper zu erstellen, der all das erledigt, anstatt diese 15 Zeilen in mehrere Dateien zu streuen?

DRY ist wichtiger, da es ein viel grundlegenderes Bedürfnis löst - redundante, effektiv verschwendete Anstrengungen zu vermeiden. Dies ist eine grundlegende Sache - man muss kein Programmierer sein, um es zu verstehen.

CQS ist eine Antwort auf die Schwierigkeit, in Sprachen ohne Unterstützung für Tracking-Effekte Code zu verstehen, der sowohl für seine Ergebnisse als auch für seine Auswirkungen ausgeführt wird. Jedoch:

1. Die Notwendigkeit, Code für seine Ergebnisse auszuführen, kann nicht vermieden werden, da dies die Grundlage für das Zusammenstellen großer Programme aus kleinen Einheiten ist.

2. Die Notwendigkeit, Code für seine Auswirkungen auszuführen, kann ebenfalls nicht vermieden werden, da der Wert der Ausführung eines Programms außerhalb der Mathematik und der theoretischen Informatik darin liegt, was es beobachtbar für uns tun kann.

3. Die Notwendigkeit, Effekte zu verursachen und Ergebnisse im selben Code zu erzielen, kann nicht vermieden werden, da wir in der Praxis sowohl Effekte als auch Komposition benötigen, nicht nur den einen oder anderen.

Die eigentliche Lösung für das Problem, dass Tracking-Effekte für Menschen ohne Hilfe zu schwierig sind, besteht natürlich darin, dass Computer uns Menschen helfen ! Ähnliches gilt für die Verfolgung komplexer Beziehungen zwischen Laufzeitwerten (z. B. die Gültigkeit von Array-Indizes), für die Ausnahmen und durch Laufzeit erzwungene Verträge (Nicht-) Lösungen darstellen.

Zusammenfassend lässt sich sagen, dass "Lösungen" wie CQS lediglich die Gestaltung von Programmen nach soliden Prinzipien, die auf der Realität basieren, behindern. Gehen Sie für trocken.