Object-Oriented Tricks: #1 Command Query Separation

OOT is a mini series on writing maintainable Object Oriented code without pulling your hair out.

Functions have side-effects. At times they change the state of the system when you least expect them to and wreak all kinds of havoc. It’s difficult to get rid of all side-effects in an Object Oriented programming paradigm. We just need to make sure to manage them so that they don’t bite us when we aren’t looking.

Managing Side Effects

One of the good ways to manage side-effects is to create a strong separation between commands and queries. In this context, a command changes the system, it has a side effect. A query returns the value of a computation or the observable state of the system.

Example

When you call a function getAmount() , you expect it to just return the amount and not change state of the system. It would be horrific if it did. Similarly, when you call setAmount() , it will have side-effects and you expect it to change the state of the system. But what do you expect setAmount() to return? Probably nothing.

Formal Definition

Command Query Separation formalises this by saying:

Functions that change state should not return values and functions that return values should not change state.

This term was coined by Bertrand Meyer in his book Object Oriented Software Construction.

Advantages

One of the advantages of following this separation is that you can easily recognize whether or not a function has a side-effect.

int m();  // query  
void n(); // command

Violation

Take a look at the call below. Is it a command or a query? Clearly, it changes the state of the system.

User u = UserService.login(username, password)

What about the user object? Why was it returned? Are you supposed to manage it? Are you supposed to call logout on it at some point in the future? Shouldn’t it rather be a simple getter?

User u = UserService.getUser();

Error Handling

Maybe login() returned the User so it could return null when it failed? We are tempted to return error codes from a command if it fails to change state. But it’s better to throw an exception, maintaining the convention that commands return void.

Gotchas

Though CQS works well most of the times, there are exceptions. Popping a stack is an example of a function that modifies state and returns a result like a query.

Element e = Stack<Element>.pop(); // stateful query

Summary

• Commands return void and queries return values.
• Use exceptions rather than returning and checking for error states.

As Martin Fowler said, it would be nice if the language itself would support this notion. The language could detect state changing methods, or at least allow the programmer to mark them. Anup Cowkur has made a handy tool to help you with this. Check it out here.

What are your views? Let’s chat on Twitter. Originally posted on the AnDevCon blog.