Where does the actual business logic belong to the Command pattern?

Examples on the web, like the example here , confuse me about the pattern Command

. In most examples, a particular command calls one of the receiver directly. Is this the only responsibility for a specific team? Where does the actual business logic belong? In the method of a execute()

specific command, or in some method on the receiver?

Another question: do we want to implement a multi-threaded command pattern, our thread pool should receive commands from Invoker

and run methods execute()

for specific commands? Do I understand correctly?

+3


source to share


2 answers


Perhaps I implemented a command with specific commands that contain the implementation of the command in simple applications, but in typical large applications, commands should do nothing more than pass the command type and any arguments. It is up to the receiver to contain or delegate the execution of the behavior.

This is because the client has to depend on specific commands. If specific teams in turn require complex dependencies to implement the behavior, the client also indirectly depends on these complex dependencies, which creates an unstable system. Instead, specific commands should not have complex dependencies, so clients can be independent of them without fear.



[I ignored your second question. Move it to a new question so we can answer it separately.]

+1


source


The business logic lies in the Receiver (most of the logic) and ConcreteCommand (some logical) classes.

The client calls Invoker => Invoker calls ConcreteCommand => ConcreteCommand . A receiver that implements the abstract Command .

The advantage . The client has no influence on changes to Command and Receiver. Invoker provides free communication between the client and the recipient. You can run multiple commands with the same Invoker.



Your understanding is correct for the front of the stream. You can think of ExecutorService as Invoker and Runnable or Callable as abstract commands and Runnable or Callable implementation classes as Concrete commands / receivers . I see ConcreteCommand playing the role of Receiver in simple multi-threaded applications.

Take a look at this question for a better understanding:

Using the Command Design Pattern

+1


source







All Articles