Другие названия: Action (Действие), Transaction (Транзакция).

Назначение: инкапсулирует запросы в объекты, позволяя передавать их в качестве параметров для обработки, ставить в очередь, протоколировать, поддерживать отмену операций и т.п.

Задача. Иногда необходимо посылать объектам запросы, ничего не зная о том, выполнение какой операции запрошено и кто является получателем. Например, в библиотеках для построения пользовательских интерфейсов встречаются такие объекты, как кнопки и меню, которые посылают запрос в ответ на действие пользователя. Но в саму библиотеку не заложена возможность обрабатывать этот запрос, так как только приложение, использующее ее, располагает информацией о том, что следует сделать. Проектировщик библиотеки не владеет никакой информацией о получателе запроса и о том, какие операции тот должен выполнить.

Решение. Паттерн Команда предлагает отправлять запросы неизвестным объектам приложения, преобразовав сам запрос в объект. Этот объект можно хранить и передавать, как и любой другой. В основе данного паттерна лежит абстрактный класс Command, в котором объявлен интерфейс для выполнения операций. В простейшей своей форме этот интерфейс состоит из одной абстрактной операции Execute. Конкретные подклассы Command определяют пару «получатель-действие», сохраняя получателя в переменной экземпляра, и реализуют операцию Execute так, чтобы она посылала запрос. У получателя же есть информация, необходимая для выполнения запроса.

С помощью объектов Command легко реализуется меню. Каждый пункт меню – это экземпляр класса MenuItem. Сами меню и все их пункты создает класс Application наряду со всеми остальными элементами пользовательского интерфейса. Класс Application отслеживает также открытые пользователем документы. Приложение конфигурирует каждый объект MenuItem экземпляром конкретного подкласса Command. Когда пользователь выбирает некоторый пункт меню, ассоциированный с ним объект MenuItem вызывает операцию Execute для своего объекта-команды, а Execute выполняет нужные действия.

 

 

Объекты MenuItem не имеют информации о том, какой подкласс класса Command они используют. Подклассы Command хранят информацию о получателе запроса и вызывают одну или несколько операций этого получателя.

Например, подкласс PasteCommand может поддерживать вставку текста из буфера обмена в документ. Получателем для PasteCommand является Document, который был передан при создании объекта. Операция Execute вызывает операцию Paste документа-получателя.

 

 

Для подкласса OpenCornmand операция Execute ведет себя по-другому: она запрашивает у пользователя имя документа, создает соответствующий объект Document, извещает о новом документе приложение-получатель и открывает этот документ.

 

 

Иногда объект MenuItem должен выполнить последовательность команд. Например, пункт меню для центрирования страницы стандартного размера можно было бы сконструировать сразу из двух объектов: CenterDocumentCommand и NormalsizeCommand. Поскольку такое комбинирование команд – явление обычное, то мы можем определить класс MacroCommand, позволяющий объекту MenuItem выполнять произвольное число команд. MacroCommand – это конкретный подкласс класса Command, который просто выполняет последовательность команд. У него нет явного получателя, поскольку для каждой команды определен свой собственный исполнитель.

 

 

В каждом из приведенных примеров паттерн Команда отделяет объект, инициирующий операцию, от объекта, который может ее выполнить. Это позволяет добиться высокой гибкости при проектировании пользовательского интерфейса. Пункт меню и кнопка одновременно могут быть ассоциированы в приложении с некоторой функцией, для этого достаточно приписать обоим элементам один и тот же экземпляр конкретного подкласса класса Command. Мы можем динамически подменять команды, что очень полезно для реализации контекстно-зависимых меню. Можно также поддерживать сценарии, если компоновать простые команды в более сложные. Все это выполнимо, потому что объект, инициирующий запрос, должен располагать информацией лишь о том, как его отправить, а не о том, как его выполнить.

Общая структура решения.

 

 

Command – команда: объявляет интерфейс для выполнения операции.

ConcreteCommand (PasteCommand, OpenCommand) – конкретная команда: определяет связь между объектом-получателем Receiver и действием; реализует операцию Execute путем вызова соответствующих операций объекта Receiver.

Invoker (MenuItem) – инициатор: обращается к команде для выполнения запроса.

Receiver (Document, Application) – получатель: располагает информацией о способах выполнения операций, необходимых для удовлетворения запроса.

Приложение создает объект ConcreteCommand и устанавливает для него получателя, а также передает указатель на эту команду соответствующему инициатору. Инициатор Invoker отправляет запрос, вызывая операцию команды Execute. Если требуется, например, поддерживать отмену выполненных действий, то ConcreteCommand перед вызовом Execute сохраняет информацию о состоянии, достаточную для выполнения отката.

Применимость. Используйте паттерн Команда, когда:

• хотите параметризовать объекты выполняемым действием, как в случае с пунктами меню MenuItem;
• нужно определять, ставить в очередь и выполнять запросы в разное время. Время жизни объекта Command необязательно должно зависеть от времени жизни исходного запроса. Если получателя запроса удается реализовать так, чтобы он не зависел от адресного пространства, то объект-команду можно передать другому процессу, который займется его выполнением;
• хотите поддерживать отмену операций: операция Execute объекта Command может сохранить состояние, необходимое для отката действий, выполненных командой. В этом случае в интерфейсе класса Command должна быть дополнительная операция Unexecute, которая отменяет действия, выполненные предшествующим обращением к Execute. Выполненные команды хранятся в списке истории. Для реализации произвольного числа уровней отмены и повтора команд нужно обходить этот список соответственно в обратном и прямом направлениях, вызывая при посещении каждого элемента команду Unexecute или Execute;
• хотите поддержать протоколирование изменений, чтобы их можно было выполнить повторно после аварийной остановки системы. Дополнив интерфейс класса Command операциями сохранения и загрузки, вы сможете вести протокол изменений во внешней памяти. Для восстановления после сбоя нужно будет загрузить сохраненные команды с диска и повторно выполнить их с помощью операции Execute;
• необходимо структурировать систему на основе высокоуровневых операций, построенных из примитивных. Такая структура типична для информационных систем, поддерживающих транзакции. Транзакция инкапсулирует набор изменений данных. Паттерн Команда позволяет моделировать транзакции. У всех команд есть общий интерфейс, что дает возможность работать одинаково с любыми транзакциями. С помощью этого паттерна можно легко добавлять в систему новые виды транзакций.

Результаты:

- команда разрывает связь между объектом, инициирующим операцию, и объектом, имеющим информацию о том, как ее выполнить;

- команды – это самые настоящие объекты, допускается манипулировать ими и расширять их точно так же, как в случае с любыми другими объектами;

- из простых команд можно собирать составные, для этого можно применить паттерн Компоновщик;

- добавлять новые команды легко, поскольку никакие существующие классы изменять не нужно.

Особенности реализации. При реализации паттерна Команда следует обратить внимание на следующие аспекты:

• насколько «умной» должна быть команда: у команды может быть широкий круг обязанностей. На одном полюсе стоит простое определение связи между получателем и действиями, которые нужно выполнить для удовлетворения запроса. На другом – реализация всего самостоятельно, без обращения за помощью к получателю. Последний вариант полезен, когда вы хотите определить команды, не зависящие от существующих классов, когда подходящего получателя не существует или когда получатель команде точно не известен. Например, команда, создающая новое окно приложения, может не понимать, что именно она создает, а трактовать окно, как любой другой объект. Где-то посередине между двумя крайностями находятся команды, обладающие достаточной информацией для динамического обнаружения своего получателя;
• поддержка отмены и повтора операций: команды могут поддерживать отмену и повтор операций, если имеется возможность отменить результаты выполнения. В классе ConcreteCommand может сохраняться необходимая для этого дополнительная информация, в том числе: объект-получатель Receiver, который выполняет операции в ответ на запрос, аргументы операции, выполненной получателем, исходные значения различных атрибутов получателя, которые могли измениться в результате обработки запроса. Получатель должен предоставить операции, позволяющие команде вернуться в исходное состояние. Для поддержки всего одного уровня отмены приложению достаточно сохранять только последнюю выполненную команду. Если же нужны многоуровневые отмена и повтор операций, то придется вести список истории выполненных команд. Проход по списку в обратном направлении и откат результатов всех встретившихся по пути команд отменяет их действие; проход в прямом направлении и выполнение встретившихся команд приводит к повтору действий. Команду, допускающую отмену, возможно, придется скопировать перед помещением в список истории. Дело в том, что объект команды, использованный для доставки запроса, скажем, от пункта меню MenuItem, позже мог быть использован для других запросов. Поэтому копирование необходимо, чтобы определить разные вызовы одной и той же команды, если ее состояние при любом вызове может изменяться. Например, команда DeleteCommand, которая удаляет выбранные объекты, при каждом вызове должна сохранять разные наборы объектов. Поэтому объект DeleteCommand необходимо скопировать после выполнения, а копию поместить в список истории. Если в результате выполнения состояние команды никогда не изменяется, то копировать не нужно – в список достаточно поместить лишь ссылку на команду Команды, которые обязательно нужно копировать перед помещением в список истории, ведут себя подобно прототипам;
• как избежать накопления ошибок в процессе отмены: при обеспечении надежного, сохраняющего семантику механизма отмены и повтора может возникнуть проблема накопления ошибок, в результате чего состояние приложения оказывается отличным от первоначального. Поэтому порой необходимо сохранять в команде больше информации, дабы гарантировать, что объекты будут целиком восстановлены. Чтобы предоставить команде доступ к этой информации, не раскрывая внутреннего устройства объектов, можно воспользоваться паттерном Хранитель.

Родственные паттерны.

Паттерн Компоновщик можно использовать для реализации макрокоманд.

Паттерн Хранитель может помочь сохранять состояние команды, необходимое для отмены ее действия.

Команда, которую нужно копировать перед помещением в список истории, ведет себя, как Прототип.