Does the Command Pattern Stand the Test of Time?
The command pattern is a behavioral design pattern in which an object is used to represent and encapsulate all the information needed to call a method at a later time.
I adore this pattern. If this pattern had a paypal account, I would donate it money on a regular basis.
In general, the notion of encapsulating the method call into an object (like the functor sin C++) is an incredibly powerful idea, because is separate the idea of selecting what to invoke and when to invoke it. Commands are used pretty much every where, WPF is probably the most obvious place, because it actually have the notion of Command as a base class that you are supposed to be using.
Other variations, like encapsulating a bunch of code to be executed later (job / task), or just being able to isolate a complex behavior into its own object, is also very useful. I base quite a lot of my architectural advice on the notion that you can decompose a system to a series of commands that you can compose and shuffle at will.
Recommendation: Use it. Often. In fact, if you go so far as to say that the only reason we have classes is to have a nice vehicle for creating commands, you wouldn’t be going far enough.
Okay, I am kidding, but I really like this pattern, and it is a useful one quite often. The thing that you want to watch for are commands that are too granular. IncrementAgeCommand that is basically wrapping Age++ is probably too much, for example. Commands are supposed to be doing something meaningful from the scope of the entire application.
Let's continue the conversation in this other post: "The Command Pattern, Not Completely in Fashion"
Published at DZone with permission of Oren Eini. See the original article here.
Opinions expressed by DZone contributors are their own.