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 and pass on the command object to Invoker object. Later on whenever client needs to execute the command, client just asks Invoker object and Invoker performs the command (maybe immediately or may queue the command for later execution).
Or is this other way around? If client needs to perform the command synchronously, client will reference the command using base class interface but will instantiate concrete command and receiver. Whenever client will need to perform the command, client will just call the execute method on base class command variable? When there will be a need of some additional logic of when a command should get executed, Invoker class will be used to keep that additional logic and client will interact with Invoker object to perform the command?
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With