All right so in this section of of course we're going to take a look at the command design pattern so
what's this all about.
Well as you probably realize ordinary C++ statements that you make such as field assignments for example
they are what I would call perishable meaning that after you are a sign of field there is no record
and you where the field has been assigned.
There are variations on the theme.
So for example if you use a specialized debugging tool such as undo D-B for example or the Intelli trace
part of Visual Studio then yes you have a historical debugger which actually records all the assignments.
But generally these statements are perishable which means that you cannot simply go ahead and undo a
field or a property assignment or whatever it is that you're doing.
And also the downside of this is you cannot take a sequence of the actions that you just made then you
cannot serialize them to some database or something because that is actually something that you sometimes
want for example for the purposes of auditing your operations you might want to get somebody to come
in and look at your records.
But of course if you have just assigned a couple of fields 100 times there is no record of the kind
of changes that lead to the final result.
So what we want to do with the command design pattern is we want to have a separate object which represents
a particular operation.
So for example you could have an object which would specify that the object X should change its field
Y to the values.
Or you could have a command which could state that object X should invoke the member function w.
For example.
Now there are plenty of uses of commands.
They're literally everywhere the most common one that you probably know is good command so whenever
you for example use Microsoft Office and you record a macro what it's doing is it's recording a sequence
of commands.
Now also when you for example get functionality such as multi-level undo or redo.
This is simply walking a sequence of commands forwards and backwards.
And similarly you get functionalities such as the macro recording that I mentioned and lots more besides.
So for example if you have a top level menu which allows you to save the file I know so a button on
the toolbar that allows you to save a file.
Both of these generate the same command pretty much and then you can store this command and you can
subsequently do something with it.
So the command design pattern is where it quite simply is an object so a command is an object which
represents an instruction or in the set of instructions as we'll see later a set of instructions that
you can perform on some system or other.
So the command typically contains all the information that is necessary for some action to be taken.
There is one thing that I wanted to mention which isn't directly tied to the subject of the command
design pattern.
And then there's this idea of command queery separation because the word command appears as part of
the command design pattern.
I felt it necessary to in big uate commands and Queries.
And it's not an easy process.
So let's just remind ourselves what a command is.
So a command is when you're asking for an action.
And typically in the concept of commands query separation a command is something which is mutable in
the sense that it causes a mutation of the object but it doesn't have a return value it doesn't have
any results so you send a command to the goblin saying please set your attack value to 2 and you don't
get any result as the end of it.
So you just invoke the command and that's pretty much it.
Now in command queery separation we separate the commands from the queries and the second part of this
is a query.
So a query is when you are asking for information like please give me your attack value and queries
are typically not causing any mutation.
So a command causes an actual change in the system and returns no value whereas a query doesn't cause
any change in the system but it does give you a value.
This idea of command query separation is something that is done quite a lot in things like distributed
databases for example.
So we have this idea of command query separation where you basically split your system into separate
components and separate means of sending commands.
So asking for changes and sending queries as well.
And those can be implemented by the same components or you can completely separate the system and actually
keep two databases kind of synchronized there are lots of variations on the idea of command cruize separation.
Now the reason why I mentioned that is because the gang of four doesn't mention queries the gang of
four only mentions the command design pattern but in the context of the gang of four book I would say
that both commands and queries since they are wrapping some instructions in an object they are both
represented by the command design pattern.
So when somebody talks about a query being sent somewhere that is also a manifestation of the command
design pattern even though as you can see the language is a bit broken here because we've sort of called
command one thing and the query another and now I'm saying that in the Gang of Four Design Patterns
the command design pattern actually encapsulates both command and queer.
I just wanted to make this point so that you don't get confused later on.
OK so let's try to summarize what we have learned about the command Design Patterns so the ideas are
fairly simple.