I cannot understand the command pattern.
I was studying patterns and no matter how much I try I can't comprehend this one. Been days of researching and something just doesn't make much sense about it.
I will try to give the definition of it that I know of, and all of my questions about it. If anything in the definition itself is wrong, please let me know too!
The command pattern separates the command of a method in it's own object, and is used to solve a few scenarios on your code, which includes making an undo/redo function of the commands or just storing those commands in general, or delaying those methods on the code. The pattern consists on having an interface (also called Abstract command), a Concrete command class, an Invoker class that takes the command request and calls the command, a Receiver class and the Client that is requesting/trying to call the method from the receiver.What I don't understand:
1- Since you can do the undo/redo or just delay the commands without it, I'm struggling to see how this helps
2- The receiver class having all the actual implementations sounds counterintuitive to me, doesn't this make one implementation bound to the others?
(I wasn't sure whether this is a begginer or intermediate question, but I'm definitely a begginer)7 Replies
i would say that the second paragraph of your description is a bit over-engineered and prescriptive... the command pattern can be as simple as a class which primarily just holds data but also has an Execute() method. the command class doesn't even have to have behaviour, it can just represent a command you give to some system -- synonymous with calling it a request.
the value of the command pattern is that it lets you treat behaviour as state
if you have a CreateUserProfileThumbnail class, you can store those commands to a database to deal with them later, you can send them across a network, you can construct a List<CreateUserProfileThumbnail> and do a foreach on them
or a Channel<CreateUserProfileThumbnail> which a background service periodically polls for work, taking load off of your main app
but you're right to see that this isn't exclusive to the command pattern. c# has other tools which can do this, like Action<T>/Func<T> etc. imo the command pattern (and a lot of 'design patterns') came about in the java days, when OOP languages didn't have good tools for these kinds of issues
what do you mean by having behaviour?
behaviour refers to what your code actually does, in a broad sense. methods, functions, stuff like that. things that execute
"you can store those commands to a database to deal with them later" you mean like make a list of those command objects (createuserprofilethumbnail)? can't you store it using the client object?
like, whenever it calls for a method of the receiver, it stores on a list an enum that represents that command and then later you can use that to anything you want (i legit just thought of this in 5 minutes so its probably not optimal at all but i hope you get the point that im struggling to see the benefits)
yeah, you can store commands in-memory too. that's why i gave the example of a List<T>
i mentioned databases just to drive home how commands let you treat behaviour as data
Ok I understand the point of most of it now but what about the "invoker" class on the pattern? Why is that important?
Shouldnt just the concrete command be enough to encapsulate the requests?
I would agree that generally you just need the command class to encapsulate the request
people often teach design patterns in a much more complex form than required
that said I don't fully get what the invoker means in your description... code might be more useful