The CQRS pattern has been around for a while and is gaining a lot of traction in our new microservices, event sourcing, multi tenancy environments. It's definitely a valid use case. Equally it adds a whole level of complexity.
They're very much related though. Interestingly if you look at what he says, He in fact determines that changing state and returning values should be deemed as two separate operations.
"It would be nice if the language itself would support this notion. I could imagine a language that would detect state changing methods, or at least allow the programmer to mark them. "
This one could argue is Martin himself notioning that using a void function should be called a "command", and a standard function that returns an object is called a "query". I'd go along with that, and a way of the compiler enforcing that rule would be even better!
"The really valuable idea in this principle is that it's extremely handy if you can clearly separate methods that change state from those that don't. This is because you can use queries in many situations with much more confidence, introducing them anywhere, changing their order. You have to be more careful with modifiers."
This is where the problem lies, your return type functions can still change global state, and this is where I feel we are not enforcing enough rules around what a function "should/is allowed" to do.
Thanks for sharing your views, I appreciate the healthy debate!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Void is perfectly good return type. In OO your methods either return state or change state.
Those that return state, don't alter the state, and will have some reasonable return type.Those that change state, don't return anything.
Tbh i'm not a fan of the description of "doing something" presented in this post. Changing the state of object describes this better in my opinion.
Martin Fowler has a post about this subject.
Edit: Failures to do that "void" operation is communicated through exception.
The CQRS pattern has been around for a while and is gaining a lot of traction in our new microservices, event sourcing, multi tenancy environments. It's definitely a valid use case. Equally it adds a whole level of complexity.
Many seem to mix CQRS (the architectural pattern) to this lot simpler practice that Martin describes. Check the post again 😊
They're very much related though. Interestingly if you look at what he says, He in fact determines that changing state and returning values should be deemed as two separate operations.
"It would be nice if the language itself would support this notion. I could imagine a language that would detect state changing methods, or at least allow the programmer to mark them. "
This one could argue is Martin himself notioning that using a void function should be called a "command", and a standard function that returns an object is called a "query". I'd go along with that, and a way of the compiler enforcing that rule would be even better!
"The really valuable idea in this principle is that it's extremely handy if you can clearly separate methods that change state from those that don't. This is because you can use queries in many situations with much more confidence, introducing them anywhere, changing their order. You have to be more careful with modifiers."
This is where the problem lies, your return type functions can still change global state, and this is where I feel we are not enforcing enough rules around what a function "should/is allowed" to do.
Thanks for sharing your views, I appreciate the healthy debate!