Command-query separation (CQS) is a principle of object-oriented computer programming. It was devised by Bertrand Meyer a part of his pioneering work on the Eiffel programming language.

It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. More formally, methods should return a value only if they are referentially transparent and hence possess no side-effects.

Connection with Design by Contract

Command-query separation is particularly well suited to a Design by Contract (DbC) methodology, in which the design of a program is expressed as assertions embedded in the source code, describing the state of the program at certain critical times. In DbC, assertions are considered design annotations---not program logic---and as such, their execution should not affect the program state. CQS is beneficial to DbC because any value-returning method (any query) can be called by any assertion without fear of modifying program state.

In theoretical terms, this establishes a measure of sanity, whereby one can reason about a program's state without simultaneously modifying that state. In practical terms, CQS allows all assertion checks to be bypassed in a working system to improve its performance without inadvertently modifying its behaviour.

Broader Software Engineering Impact

Even beyond the connection with Design by Contract, CQS is considered by its adherents to have a simplifying effect on a program, making its states (via queries) and state changes (via commands) more comprehensible in a manner reminiscent of how Edsger Dijkstra's admonition against gotos did the same for control flow.

CQS can also be applied outside of object-oriented programming. There is nothing inherently object-oriented about the separation of side-effects and return values, and so CQS can be profitably applied to any programming paradigm that requires reasoning about side-effects.

Criticism

Some claim that CQS makes it difficult to implement re-entrant and multi-threaded software correctly. The reasoning goes that some operations inherently possess both a return value and a side-effect, and CQS would require this operation to be implemented as two separate method calls: namely, a command followed by a query. This opens the door to race conditions when several callers get their commands and queries interleaved, with each caller's query returning results relating to another caller's command. While such problems can be solved with CQS by using careful concurrency control around sets of calls, they can also trivially solved by breaking CQS and implementing the operation as a single method that encapsulates the necessary locking. Hence, the benefits of CQS may find themselves sacrificed for expediency.