Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Role of Invoker class in Command pattern

let's assume that we have command pattern implemented in this way

I am a bit confused about the role of Invoker here. From my point of view:

  1. If we do need history (or any kind of action before command execution), then there is a sense in making this class. But then it breaks Single responsibility principle, yeah? Now it's not only a delegate, it also stores history there.
  2. If we don't need history, I don't see a goal of creating this invoker, that simply performs delegating. Is the only reason for it is just a assumption, that we would need some kind of logic before/after command execution in the future?

Or am I missing something?

like image 868
Иван Николайчук Avatar asked May 29 '16 16:05

Иван Николайчук


People also ask

What are the important roles in the command pattern?

Four terms always associated with the command pattern are command, receiver, invoker and client. A command object knows about receiver and invokes a method of the receiver. Values for parameters of the receiver method are stored in the command.

What is invoker class in Java?

Invoker hides the detail of calling into application endpoint implementation. Container hands over an implementation of Invoker to JAX-WS runtime, and jax-ws runtime calls invoke(java. lang. reflect. Method, java.

What would you use to implement the command pattern?

In a classic implementation, the command pattern requires implementing four components: the Command, the Receiver, the Invoker, and the Client.

When use command design pattern describe the role of each participant in it?

Usage of command pattern: It is used: When you need parameterize objects according to an action perform. When you need to create and execute requests at different times. When you need to support rollback, logging or transaction functionality.


1 Answers

If we do need history (or any kind of action before command execution), then there is a sense in making this class. But then it breaks Single responsibility principle, yeah? Now it's not only a delegate, it also stores history there.

I fully agree with Andreas answer. If you think that you are executing multiple responsibilities, break them into different methods.

Single Responsibility principle is good to hear but we should not give too much of attention to that principle. If you strictly follow that principle, I am sure that code base is cluttered with too many small classes. I don't think any of big projects in software industry use that principle. The best thing we can do have different methods in same class for different actions.

If we don't need history, I don't see a goal of creating this invoker, that simply performs delegating. Is the only reason for it is just a assumption, that we would need some kind of logic before/after command execution in the future?

The core USP of Command pattern is Invoker. It decouples Client ( Sender) and Receiver.

From oodesign article:

The Client asks for a command to be executed. The Invoker takes the command, encapsulates it and places it in a queue, in case there is something else to do first, and the ConcreteCommand that is in charge of the requested command, sending its result to the Receiver.

I have explained the role of Invoker in below SE question:

Command Pattern seems needlessly complex (what am I failing to understand?)

like image 152
Ravindra babu Avatar answered Oct 25 '22 22:10

Ravindra babu