Определение: инкапсулировать запрос в объект, позволяя вам параметризировать клиента с помощью различных запросов, запросов очереди или журналов запросов записи, а также предоставить функции отзыва и восстановления команды.
Тип: поведенческий паттерн
Классовая диаграмма:
Структура командного режима
Как следует из имени, командный режим - это инкапсуляция команд. Во -первых, давайте посмотрим на основную структуру на диаграмме класса команд:
Командный класс: это абстрактный класс, который объявляет команды, которые необходимо выполнить. Вообще говоря, метод выполнения должен быть опубликован публике для выполнения команды.
ConceteCommand Class: класс реализации класса команд, реализует методы, объявленные в абстрактном классе.
Клиент класс: конечный класс вызова клиента.
Функции приведенных выше трех классов должны быть легче понять. Давайте сосредоточимся на классе Invoker и классе Decepier.
Класс Invoker: звонящий несет ответственность за вызов команд.
Класс приемника: получатель отвечает за получение и выполнение команд.
Говоря о том, что так называемая инкапсуляция команд-это не что иное, как написание серии операций в метод, а затем его называют клиентом. Это отражено на классной диаграмме. Для завершения инкапсуляции команд требуется только класс ConceteCommand и класс клиента. Даже если это идет дальше, чтобы повысить гибкость, для соответствующей абстракции можно добавить командный класс. Какова функция этого вызывающего абонента и приемника?
На самом деле, вы можете думать с другой точки зрения: если вы просто инкапсулируете некоторые операции в качестве команды для других, как его можно назвать шаблоном? Как поведенческая модель, режим команд должен сначала достичь низкой связи. Только когда степень связи низкая, может быть улучшена гибкость. Цель добавления ролей абонента и приемника именно для этого.
пример:
Моделирование работы телевизора включает в себя команды включения, выключения и смены. Код выглядит следующим образом
// интерфейс для выполнения команды команды общедоступного интерфейса {void execute (); } // Command Receiver Pretiver Public Class TV {public int CurrentChannel = 0; public void turnon () {System.out.println («Televisino включен»); } public void Surwoff () {System.out.println («Телевидение выключено.»); } public void ChangeChannel (int Channel) {this.currentChannel = Channel; System.out.println («Теперь телеканал - + канал); }} // Выключить команду ConcreteCommand public Class CommandOn Commandment Command {private TV mytv; public Commandon (TV TV) {myTV = TV; } public void execute () {mytv.turnon (); }} // Выключить команду ConceteCommand Public Class CommandOff Commandom Command {Private TV MYTV; public CommandOff (TV TV) {myTV = TV; } public void execute () {mytv.turnoff (); }} // Команда переключения канала ConceteCommand public Class CommandChange Command {Private TV MYTV; частный int -канал; public CommandChange (TV TV, int Channel) {mytv = TV; this.channel = канал; } public void execute () {mytv.changechannel (Channel); }} // это можно рассматривать как удаленный контроль Invoker Public Class Control {Private Command Oncommand, OffCommand, ChangeChannel; public Control (Command On, Command Off, Command Channel) {onCommand = on; OffCommand = off; ChangeChannel = Channel; } public void turnon () {oncommand.execute (); } public void -поворот () {offcommand.execute (); } public void ChangeChannel () {ChangeChannel.execute (); }} // тест класс клиент общедоступный класс клиент {public static void main (string [] args) {// получатель командного получателя TV mytv = new TV (); // Power-On Command ConceteCommond Commandon on = new Commandon (mytv); // Команда Shutdown ConceteCommond CommandOff off = new CommandOff (MYTV); // Команда переключения канала ConceteCommond CommandChange Cannel = New CommandChange (MYTV, 2); // объект управления командой CONTROL CONTROL = NEW CONTROL (ON, OFF, Channel); // power-on control.turnon (); // переключение канала Control.ChangeChannel (); // shut control.turnoff (); }}Результаты исполнения
Televisino включен. Теперь телеканал 2 - телевизор отключен.
Преимущества и недостатки командного режима
Прежде всего, командный режим очень инкапсуляция: каждая команда инкапсулируется, и для клиента соответствующая команда вызывается столько, сколько необходима функция, не зная, как выполняется команда. Например, существует набор команд операции файла: Создайте новый файл, скопируйте файл и удалите файл. Если эти три операции инкапсулированы в командный класс, клиент должен знать, что есть эти три командных класса. Что касается логики, инкапсулированной в командном классе, клиенту не нужно знать.
Во -вторых, командный режим имеет хорошую масштабируемость. В командном режиме самая основная инкапсуляция операций в классе приемника и вторичная инкапсуляция командных классов этих основных операций. При добавлении новых команд написание командного класса обычно не с нуля. Существует большое количество классов приемника для вызова, и есть также большое количество командных классов для вызова, и код очень используется. Например, в операции файла нам нужно добавить команду для вырезания файла, и нам нужно только объединить две команды копирования файла и удаления файла, что очень удобно.
Наконец, давайте поговорим о недостатках командного режима, то есть, если есть много команд, это будет головная боль для развития. Особенно многие простые команды - это всего лишь несколько строк кода для реализации. Если вы используете командный режим, вам не нужно беспокоиться о том, насколько проста это команда, вам нужно написать командный класс, чтобы инкапсулировать его.
Применимые сценарии для командного режима
Для большинства функций режима запроса ответа режим ответа он более подходит для использования командного режима. Как говорится в определении командного режима, командный режим более удобен для реализации таких функций, как ведение журнала и операции отмены.
Суммировать
Использовать режим в случае - это очень запутанный вопрос для всех разработчиков. Иногда, из -за предвидя некоторых изменений в требованиях, определенный шаблон проектирования используется для гибкости и масштабируемости системы, но это предсказуемое требование не является. Напротив, поступило много непредвиденных требований, в результате чего использовался шаблон проектирования, играющий противоположную роль при изменении кода, так что вся команда проекта жаловалась. Я считаю, что каждый программист столкнулся с таким примером. Поэтому, основываясь на принципе гибкой разработки, когда мы разрабатываем программы, если мы можем решить их хорошо, не используя определенную шаблон в соответствии с текущими потребностями, мы не должны его вводить, потому что не сложно ввести шаблон проектирования. Мы можем сделать это в системе, когда нам это действительно нужно, чтобы использовать его и представить этот шаблон дизайна.
Возьмите командный режим в качестве примера. В нашей разработке функция режима запроса-ответа очень распространена. Вообще говоря, мы инкапсулируем операцию ответа на запрос в метод. Этот инкапсулированный метод можно назвать командой, но не командным режимом. Независимо от того, следует ли рассматривать этот дизайн до высоты шаблона, необходимо учитывать отдельно, потому что, если используется командный режим, должны быть введены две роли вызывающего и приемника. Логика, первоначально размещенная в одном месте, разбросана по трем категориям. При проектировании необходимо рассмотреть вопрос о том, стоит ли эта стоимость.