- 20 October 2016
- Ruby Design
- Command-Query Separation
Today's post will be more theoretical rather than practical. But it's worth reading because Command-Query Separation allows you to improve design of methods. So today we will discuss CQS.
Let's see how Wikipedia describes it:
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.
Very simple and reasonable idea, but people usually forget about it during development. So each method should be either a Command which make some action or Query which returns a value.
Following this principle you will never break another very useful rule - Tell Don't Ask. Because you will either send commands (Tell) or queries (Ask).
For example we can go through simple CRUD (Create, Read, Update, Delete) in Rails application.
We can see three commands here: Create, Update and Delete. They change state of the system. Read - is a typical query, it shouldn't affect our system. It should have no side effects.
The main benefit from using this approach is a guarantee that calling Query you can be sure that the state of system will not change. It has no side effects. After a calling Command, state of a system will change in an expected way.
Another benefit that such code is much easier to test.
Following this principle you will be able to name methods more properly. For Queries it will be nouns. For example:
Names of these methods show us their purpose.
As usually I want to show you CQS on example. It shows how important to pick proper names for methods and separate them by Command and Query.
User class with two methods:
class User def validate_email(email) @email = email if /^long_regexp_to_check_email$/.match(email) end def email @email || 'No email' end end
It's a bad code. Let's try to understand why. First of all name of method
validate_email doesn't correspond to its behavior. Besides validation this code has unexpected side-effect: it sets
nil value. That's why
Also, we can't reuse method
validate_email if we really just want to validate email. Because it sets
Let's rewrite that code using CQS:
class User attr_reader :email def set_email(email) @email = valid_email?(email) ? email : 'No email' end private def valid_email?(email) !!(/^long_regexp_to_check_email$/.match(email)) end end
This code is much better. Method names are self-explanatory:
valid_email?. We see that
set_email it's a Command that will set
valid_email? it's a Query which returns
Also we can easily re-use
valid_email? inside class without any unexpected side-effects.
set_email, we can easily pull it out into
Even on such simple example we see profit of using Command-Query Separation (CQS). In real project this approach will allow you to improve your code and make it more readable. Also one of the biggest benefits of CQS is side-effect free methods - Queries.