Trennung der Befehl-Abfrage (CQS), auch genannt Verantwortungsabtrennung der Befehl-Abfrage (CQRS), ist ein Grundsatz der befehlenden Computerprogrammierung. Es wurde von Bertrand Meyer als ein Teil seiner Pionierarbeit an der Programmiersprache von Eiffel ausgedacht.

Es stellt fest, dass jede Methode entweder ein Befehl sein sollte, der eine Handlung oder eine Abfrage durchführt, die Daten dem Anrufer, aber nicht beiden zurückgibt. Mit anderen Worten sollte das Stellen einer Frage nicht die Antwort ändern. Mehr formell sollten Methoden einen Wert nur zurückgeben, wenn sie Verweisungs-durchsichtig sind und folglich keine Nebenwirkungen besitzen. Es ist beachtenswert, dass die starre Durchführung dieser Spezifizierung das Verfolgen der Zahl von Zeitabfragen macht, sind im Wesentlichen unmöglich ausgegeben worden; es ist klar als eine Programmierrichtlinie aber nicht eine Regel für das gute Codieren, wie das Vermeiden des Gebrauches eines goto von einer verschachtelten Schleife beabsichtigt.

Verbindung mit dem Design durch den Vertrag

Trennung der Befehl-Abfrage wird besonders einer Methodik des Designs durch den Vertrag (DbC) gut angepasst, in der das Design eines Programms als im Quellcode eingebettete Behauptungen ausgedrückt wird, den Staat des Programms in bestimmten kritischen Zeiten beschreibend. In DbC werden Behauptungen als Designanmerkungen - nicht Programm-Logik - und als solcher betrachtet, ihre Ausführung sollte den Programm-Staat nicht betreffen. CQS ist für DbC vorteilhaft, weil jede wertzurückgebende Methode (jede Abfrage) durch jede Behauptung ohne Angst davor genannt werden kann, Programm-Staat zu modifizieren.

In theoretischen Begriffen gründet das ein Maß der Vernunft, wodurch man über einen Staat eines Programms vernünftig urteilen kann, ohne gleichzeitig diesen Staat zu modifizieren. In praktischen Begriffen erlaubt CQS allen Behauptungskontrollen, in einem Arbeitssystem umgangen zu werden, um seine Leistung zu verbessern, ohne sein Verhalten unachtsam zu modifizieren. CQS kann auch das Ereignis von bestimmten Arten von heisenbugs verhindern.

Breiterer Einfluss auf Softwaretechnik

Sogar außer der Verbindung mit dem Design durch den Vertrag, wie man betrachtet, hat CQS von seinen Anhängern eine Vereinfachungswirkung auf ein Programm, seine Staaten (über Abfragen) und Zustandsänderungen (über Befehle) verständlicher gewissermaßen erinnernd daran machend, wie die Warnung von Edsger Dijkstra gegen gotos für den Kontrollfluss dasselbe gemacht hat.

CQS ist zur objektorientierten Methodik gut passend, aber kann auch außerhalb der objektorientierten Programmierung angewandt werden. Es gibt nichts von Natur aus Objektorientiertes über die Trennung von Nebenwirkungen und Rückwerten, und so kann CQS auf jedes Programmierparadigma rentabel angewandt werden, das das Denken über Nebenwirkungen verlangt.

Nachteile

CQS kann es schwieriger machen, einspringende und Mehrgewindesoftware richtig durchzuführen. Dieser Anspruch entsteht gewöhnlich, wenn nicht sicheres Muster einfädeln, wird verwendet, um die Befehl-Anfragentrennung durchzuführen.

Ein einfaches Beispiel eines Musters, das CQS bricht, aber für die Mehrgewindesoftware nützlich ist:

private interne Nummer x;

öffentliche interne Nummer increment_and_return_x

{\

Schloss x;//durch einen Mechanismus

x = x + 1;

interne Nummer x_copy = x;

schließen Sie x auf;//durch einen Mechanismus

geben Sie x_copy zurück;

}\

</Quelle>

Ein allgemeines CQS Muster verwendbar nur in einzelnen Gewindeanwendungen:

private interne Nummer x;

öffentlicher int Wert

{\

geben Sie x zurück;

}\

Leere increment_x

{\ x = x + 1;}\</Quelle>

Sogar in Einzeln-Gewindeprogrammen ist es manchmal wohl bedeutsam günstiger, eine Methode zu haben, die eine vereinigte Abfrage und Befehl ist. Martin Fowler zitiert die Methode eines Stapels als ein Beispiel.

Siehe auch

• Fließende Schnittstelle

Weiterführende Literatur

Links

• Erklärung auf dem Bliki von Martin Fowler
• Befehl-Anfragenverantwortungsabtrennung
• Warum Befehl-Anfragentrennung für SOA erforderlich ist