Command-Query Separation

I’ve been dropping some short but, hopefully, meaningful posts about subjects within software development like Names and Don’t Repeat Yourself. These appear to be getting some interest so I’m going to look at putting together more short to the point titbits, or tidbits, of recommended software development best practices.

So this week’s titbit is the aim of incorporating the Command-Query Separation principle into our code.

The main goal of Command-Query is that we should aim to write our code in such a way that methods either do something or give us something but that they do NOT do both.

  • Commands: Do something; change the state of the system.
  • Queries: Give us something; give us back a result but do not change the state of the system.

This concept was coined by Bertrand Meyer the author of Object-Oriented Software Construction in the late 1980s and as mentioned above is quite straightforward to understand but not as easy to implement all the time.

Martin Fowler wrote an article in 2005 that provides a good example of where this is the case. If you are using a 3rd party data structure which does not follow this rule and you perform a query on that data structure the state of the system may be changed as a result, thereby breaking the principle. He also continues with this train of thought, we should aim to follow these best practices where we can and when we can but that is not always the case.

My view here is we can either review our implementation, and look to improve it if it’s a break we are causing, or we can accept that these things happen but try to work around the issue so we ensure our code is as clean and expressive as we can make it.

A quote from one of my university lecturers was “Write your code like the person taking it on after you are an axe-wielding murder who knows where you live.”, a bit dramatic but the point is there; we should aim to make our code clean and clear and this kind of decoupling is certainly something we should all be considering.

.Net: C#

Ok, so I’ve talked about the .Net Framework and .Net Core now I think it’s time we have a bit of an introduction to a .Net language, specifically C# (pronounced ‘C Sharp’).

C# is a member of the C family of languages, this includes C, C++, Java, Objective-C, and many others. It is commonly referred to as a general-purpose, type-safe, object-oriented programming language. Let’s quickly break this down:

  • General-Purpose: Means the language has been designed for application in many different domains.
  • Type-Safe: Means behaviours within our programs are well defined.
  • Object-oriented: Means we create our programs around the concept of real-world objects. See this post.

The core syntax for C# is very similar to that of Java but it is not a clone, at least not directly. C# was primarily modelled after Visual Basic (another .Net Language) and C++ (developed by Bjarne Stroustrup.

C#, however, gives us a lot of what other languages do, including overloading, overriding, structs, enums, and delegates (callbacks), but also gives use features more commonly found in functional languages, like F# and LISP, such as anonymous types and lambda expressions. All of which I will be writing about in the future.

The intention of the language was to be a simple yet modern language which provides portability and deployment to different types of environments. With the release of .Net Core, I’d say it is certainly living up to expectations.

The latest stable release of C# is currently at 7.3 as of May 2018 and the latest Preview release is at 8.0. Keep an eye out for a post that gives an overview of the changes provided to us at each release.

I won’t go into too much detail for this post as I want to start writing smaller posts targeting specific parts of the C# language.