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 .
8-398: CQS may refer to: Command-query separation Consolidated Quotation System Color Quality Scale CQS (Asset Manager) , managed by Michael Hintze Topics referred to by the same term [REDACTED] This disambiguation page lists articles associated with the title CQS . If an internal link led you here, you may wish to change
16-399: 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 . Command-query separation is particularly well suited to a design by contract (DbC) methodology, in which
24-401: 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 . Even beyond the connection with design by contract, CQS
32-565: 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. CQS is well-suited to the object-oriented methodology, but can also be applied outside of object-oriented programming. Since the separation of side effects and return values is not inherently object-oriented, CQS can be profitably applied to any programming paradigm that requires reasoning about side effects. Command query responsibility segregation ( CQRS ) generalises CQS to services, at
40-485: Is useful for multi-threaded software because it solves the complexity of locking for all other parts of the program, but by doing so it doesn't follow CQS because the function both mutates state and returns it: Here is a CQS-compliant version. Note that it is safely usable only in single-threaded applications. In a multithreaded program, there is a race condition in the caller, between where increment() and value() would be called: Even in single-threaded programs, it
48-484: The architectures level: it applies the CQS principle by using separate Query and Command interfaces and usually data models to retrieve and modify data, respectively. CQS can introduce complexities for implementing reentrant and multithreaded software correctly. This usually occurs when a non-thread-safe pattern is used to implement the command-query separation. Here is a simple example that does not follow CQS, but
56-473: 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
64-415: The link to point directly to the intended article. Retrieved from " https://en.wikipedia.org/w/index.php?title=CQS&oldid=864768238 " Category : Disambiguation pages Hidden categories: Short description is different from Wikidata All article disambiguation pages All disambiguation pages Command-query separation It states that every method should either be
#789210