Где находится фактическая бизнес-логика в шаблоне команд?

Примеры в интернете, как примерздесь , смутили меня относительно шаблона Command в большинстве примеров конкретная команда непосредственно вызывает один из методов получателя. Является ли это единственной ответственностью конкретного командования? Где же находится настоящая бизнес-логика? В методе execute() конкретной команды или в каком-то методе на приемнике?

Другой вопрос, если мы хотим реализовать многопоточный шаблон команд, наш пул потоков должен получать команды от Invoker и запустить методы execute() конкретных команд? Верно ли мое понимание?

2 3
multithreading design-patterns command-pattern

2 ответа:

Либо это возможно, и я реализовал команду с конкретными командами, которые содержат реализацию команды в простых приложениях, но в типичных больших приложениях команды не должны делать ничего, кроме передачи типа команды и любых аргументов. Это зависит от получателя, чтобы содержать или делегировать реализацию поведения.

Это происходит потому, что клиент должен зависеть от конкретных команд. Если конкретные команды, в свою очередь, требуют сложных зависимостей, чтобы реализуя поведение, клиент косвенно зависит и от этих сложных зависимостей, что делает систему нестабильной. Вместо этого конкретные команды не должны иметь сложных зависимостей, чтобы клиенты могли зависеть от них без страха.

[я проигнорировал ваш второй вопрос. Пожалуйста, переместите его на новый вопрос, чтобы мы могли ответить на него отдельно.]

1

Бизнес-логика лежит вприемнике (большая часть логики) иконкретной команде (некоторые логические классы).

Клиент вызывает Invoker => Invoker вызывает конкретную команду => ConcreteCommand вызывает метод Receiver, который реализует абстрактный метод Command.

Преимущество : на клиента не влияют изменения в команде и приемнике. Вызыватель обеспечивает свободное соединение между клиентом и получателем. Вы можете выполните несколько команд с одним и тем же Вызывателем.

Ваше понимание правильно на фронте потока. Вы можете рассматривать ExecutorService как Invoker и Runnable или Callable как абстрактные команды и классы реализации Runnable или Callable Как конкретные команды/приемники. Я вижу, чтоConcreteCommand сам играет рольприемника в простых многопоточных приложениях.

Взгляните на этот вопрос для лучшего понимания :

Использование шаблона проектирования команд

1