Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I was recently refactoring a method that was both a command and a query method.
After separating it into a one command method and one query method, I found that there are now multiple places in the code where I am calling the command then getting the value from the query, which seems like a violation of the DRY principle.
But if I were to wrap that common code into a method, that method would be both command and a query. Is this acceptable?
There are always trade offs to consider between conflicting design principles. The way to resolve it is to look at the underlying reasons behind the principles. In this case, being unable to run a query without running the command is problematic, but being unable to run a command without running the query is generally harmless. As long as there's a way to run the query standalone, I see no reason not to add the query result to the command, especially if done something like this:
QueryResult command()
{
// do command stuff
return query();
}
I haven't heard of Command-Query-Separation(CQS) before, but it seems that it would relate to Single Responsibility Principle(SRP), which states that a function/class ideally should be responsible for doing one thing and one thing only.
If your command code is 20 lines of code and query code is another 30 lines and they are all in one function body, clearly you are violating SRP and I'd assume CQS as well and those two pieces of logic should be separated from each other.
However, going with your hypothetical example, I would most likely create a wrapper method that would combine your command and query so that DRY isn't violated in numerous places in the code. I'd also wouldn't consider this to be SRP (and maybe CQS) violation, because the wrapper still has only one responsibility: to combine command with a query and create a higher level abstraction that is easier to consume.
I think wrapper method is perfectly acceptable solution and to illustrate that, let's take your example one step further. What if you had to run 2 queries instead of 1 and then do a command action based on that. So your 2 lines of code would be 6 or 8. What if there was some data validation/checking between one and the other, so now you have 15 lines of code. Would you think twice about creating a wrapper that does all that, rather than sprinkling those 15 lines in multiple files?
DRY is more important, since it solves a much more fundamental need - avoiding redundant, effectively wasted effort. This is a fundamental thing - one need not be a programmer to understand it.
CQS is a response to the difficulty, in languages with no support for tracking effects, of understanding code that is executed both for its results and its effects. However:
The necessity to execute code for its results cannot be avoided, because this is the basis for composing large programs from small units.
The necessity to execute code for its effects cannot be avoided either, because, outside of mathematics and theoretical computer science, the value of running a program lies on what it observably can do for us.
The necessity to cause effects and produce results in the same code cannot be avoided, because, in practice, we need both effects and compositionality, not just one or the other.
The actual solution to the problem of tracking effects being too hard for unaided humans is, of course, to have computers aid us humans! A similar thing can be said about tracking intricate relationships between runtime values (such as the validity of array indices), for which exceptions and runtime-enforced contracts constitute (non-)solutions.
In conclusion, "solutions" like CQS merely get in the way of designing programs according to sound principles based on reality. Go for DRY.
