Command-query separation
 |
This article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (February 2008) |
Command-query separation (CQS) is a principle of imperative computer programming. It was devised by Bertrand Meyer as 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. In other words, asking a question should not change the answer. More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.
Contents |
[edit] 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. CQS may also prevent the occurrence of certain kinds of heisenbugs.
[edit] Broader impact on software engineering
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 is well-suited to the object-oriented methodology, but 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.
[edit] Drawbacks
CQS can make it more difficult to implement re-entrant and multi-threaded software correctly. This claim usually arises when a non-thread-safe pattern is used to implement the command query separation.
A simple example of a pattern that breaks CQS but is useful for multi-threaded software:
private int x; public int increment_and_return_x() { lock x; // by some mechanism x=x+1; unlock x; // by some mechanism return x; }
A common CQS pattern usable only in single threaded applications:
private int x; public int value() { return x; } void increment_x() { x=x+1; }
[edit] See also
[edit] Further reading
- Meyer, Bertrand (1988). Object-oriented Software Construction. Prentice Hall. ISBN 0136290493.
