Is Invoker class optional in Command design pattern? Client needs to instantiate Concrete Command and Receiver for the command. Does client always need to instantiate Invoker an
The purposes of Command pattern are usually 1) Make a set of different operations share the same type so they can be processed by the same code 2) separate operation marshalling/creation from operation invocation. The Reciever is explicitly required for purpose 2.
If you invoke right after creation or if the Reciever is playing the role of invoker, there's no single-purpose, stand-alone invoker. Whether that means that there's no invoker is really a philosophical question :)
Look at it this way: You /can/ seperate the creation, scheduling and invocation. That doesn't mean that you have to implement them as three separate classes. It's just the logical roles that are involved in the Command pattern life cycle.
EDIT: I guess the single responsibility principle argues that you should separate them, but there's such a thing as commen sense :) Local conditions can and should be observed.
As we know, java.lang.Runnable is one of the examples of command pattern where Thread class works as an invoker. We pass object of a Runnable class to Thread class and say start/run.
But we never create a client class which can invoke main thread.
So an invoker is not optional but it is not tightly coupled to client. So UML of command pattern never shows any relationship among client class and invoker class.
Another answer related to this question.