- Singleton Pattern
- Bridge Pattern
- Composite Pattern
- Facade Pattern
- Adapter Pattern
- Decorator Pattern
- Factory Pattern Part 1
- Factory Pattern Part 2
- Proxy Pattern
- Observer Pattern
- Command Pattern
- Chain of Responsibility Pattern
As I said, a command object is actually representative of a verb, rather than a noun like most objects are. Another way to say it is that the command pattern is a way of encapsulating the invocation of a method. It is simply an abstraction layer between the object that implements a method and the object that wishes to invoke that method. This is most powerful in the world of user interface. As usual, this will probably make a little more sense with a code example.
Let’s say that we’re making an alarm clock app, probably very similar to the one on your cell phone. It lists several alarms that you can have, and in the case of this app that number can be anywhere between zero and infinity, unlike the mere 4 alarms that my little flip phone maxes out at. For this app we’ll need an
Alarm object that contains the status and settings of the alarm. Right now, we’re only concerned about a few specific methods that it implements:
For each one of these methods, we’ll create a command object to encapsulate it:
Notice that the command objects each follow an interface. In this example, the interface defines only one method and each of those methods only calls one function themselves. If this is the case, you probably can just ignore doing things like this and just use callback functions, which is essentially using the functions as the command objects themselves, in which case you’re still using the command pattern but you don’t realize it because it’s always just been called a callback function.
Now we’ll need to use the command objects. We’ll be giving them over to a UI object that adds a button to the screen and when the button is clicked it runs the
execute method on the command object that was passed into it. Of course, it knows which method to invoke because all of the commands use the same interface.
The Command pattern has four main parts that make it up. The first and most obvious is the command object. By now you know what this is. The other three parts are the client, invoker, and receiver. The client is the code that creates the command object and passes it on to the invoker. That would mean that in the previous code snippet, the code within the
for loop is the client. The invoker is the object that utilizes the command object and calls its method(s). Finally, the receiver is the object that the command is making calls on, which in this case are the
If you’d like to see an example of something that is a compromise between the above example of command object and just using callbacks, then take a look below, where I use “callback factories” (functions that create callbacks):
Not much to it. Instead of creating an object that has a method to be called, we just create a function that returns a callback. It’s mostly useless unless it’ll actually do more than just call the one specific function. The primary reason the Command Pattern exists as an object that follows an interface is simply because first-class functions (and/or lambdas) don’t (or previously didn’t) exist in the languages this pattern was designed for.
This can also be used as a means to make your code a bit more secure. Assuming that the invoker is third party code, it could possibly make alterations to the receiver’s method by adding, changing, or nullifying its properties. This is extremely unlikely though.
Here’s what the invoker code looks like when adjusted to use the callback factories:
That’s just about all I have. I didn’t mention that the command pattern can be used as a means to create the ability to undo actions as well, but I don’t want to drag this on too long, so I won’t show you how to do this. Outside of using plain callbacks, the Command pattern has pretty limited use. There are times where it can come in quite handy, though, and you’ll feel pretty special for having utilized a design pattern.