指令模式就是對指令的封裝，下文給大家介紹了指令模式類別圖中的基本結構，對java設計模式之命令模式相關知識有興趣的朋友一起看看吧
定義：將一個請求封裝成一個對象，從而讓你使用不同的請求把客戶端參數化，對請求排隊或記錄請求日誌，可以提供命令的撤銷和恢復功能。
類型：行為類別模式
類別圖：
#命令模式的結構
# 顧名思義，指令模式是對指令的封裝，先來看看指令模式類別圖中的基本結構：
Command類別：是一個抽象類別，類別中對需要執行的指令進行聲明，一般來說要對外公佈一個execute方法用來執行指令。
ConcreteCommand類別：Command類別的實作類，將抽象類別中宣告的方法實作。
Client類別：最終的客戶端呼叫類別。
以上三個類別的作用應該是較好理解的，以下我們將重點放在Invoker類別和Recevier類別中。
Invoker類別：呼叫者，負責呼叫指令。
Receiver類別：接收者，負責接收指令並且執行指令。
所謂對命令的封裝，說白了，無非就是把一系列的操作寫到一個方法中，然後供客戶端調用就行了，反映到類別圖上，只需要一個ConcreteCommand類別和Client類別就可以完成命令的封裝，即使再進一步，為了增加靈活性，可以再增加一個Command類別進行適當地抽象，這個呼叫者和接收者到底是什麼作用呢？
其實大家可以換一個角度去想：假如僅僅是簡單地把一些操作封裝起來當作一條指令供別人調用，怎麼能稱為一種模式呢？命令模式作為一種行為類別模式，首先要做到低耦合，耦合度低了才能提高靈活性，而加入呼叫者和接收者兩個角色的目的也正是為此。指令模式的一般
程式碼如下：
class Invoker {
private Command command;
public void setCommand(Command command) {
this.command = command;
}
public void action(){
this.command.execute();
}
}
abstract class Command {
public abstract void execute();
}
class ConcreteCommand extends Command {
private Receiver receiver;
public ConcreteCommand(Receiver receiver){
this.receiver = receiver;
}
public void execute() {
this.receiver.doSomething();
}
}
class Receiver {
public void doSomething(){
System.out.println("接受者-业务逻辑处理");
}
}
public class Client {
public static void main(String[] args){
Receiver receiver = new Receiver();
Command command = new ConcreteCommand(receiver);
//客户端直接执行具体命令方式（此方式与类图相符）
command.execute();
//客户端通过调用者来执行命令
Invoker invoker = new Invoker();
invoker.setCommand(command);
invoker.action();
}
} 透過程式碼我們可以看到，當我們呼叫時，執行的時序首先是呼叫者類，然後是指令類，最後是接收者類別。也就是說一條指令的執行被分成了三步，它的耦合度要比把所有的操作都封裝到一個類別中要低的多，而這也正是指令模式的精髓所在：把指令的呼叫者與執行者分開，使雙方不必關心對方是如何運作的。
指令模式的優缺點
# 首先，指令模式的封裝性很好：每個指令都被封裝起來，對於客戶端來說，需要什麼功能就去呼叫對應的命令，而無需知道命令具體是怎麼執行的。例如有一組檔案操作的指令：新建檔案、複製檔案、刪除檔案。如果把這三個操作都封裝成一個命令類，客戶端只需要知道有這三個命令類即可，至於命令類中封裝好的邏輯，客戶端則無需知道。
其次，命令模式的擴展性很好，在命令模式中，在接收者類別中一般會對操作進行最基本的封裝，命令類別則透過對這些基本的操作進行二次封裝，當增加新命令的時候，對命令類別的編寫一般不是從零開始的，有大量的接收者類別可供調用，也有大量的命令類別可供調用，程式碼的複用性很好。例如，在文件的操作中，我們需要增加一個剪切文件的命令，只需要把複製文件和刪除文件這兩個命令組合一下就行了，非常方便。
最後請先說一下指令模式的缺點，那就是指令如果很多，發展起來就要頭痛了。特別是很多簡單的指令，實作起來就幾行程式碼的事，而使用指令模式的話，不用管指令多簡單，都需要寫一個指令類別來封裝。
命令模式的適用場景
對大多數請求-回應模式的功能，較適合使用指令模式，如指令模式定義說的那樣，命令模式對實現記錄日誌、撤銷操作等功能比較方便。
總結
# 對於一個場合到底用不用模式，這對所有的開發人員來說都是一個很糾結的問題。有時候，因為預見到需求上會發生的某些變化，為了系統的靈活性和可擴展性而使用了某種設計模式，但這個預見的需求偏偏沒有，相反，沒預見到的需求倒是來了不少，導致在修改程式碼的時候，使用的設計模式反而起了相反的作用，以至於整個專案組怨聲載道。這樣的例子，我相信每個程式設計者都遇過。所以，基於敏捷開發的原則，我們在設計程式的時候，如果按照目前的需求，不使用某種模式也能很好地解決，那麼我們就不要引入它，因為要引入一種設計模式並不困難，我們大可以在真正需要用到的時候再對系統進行一下，引入這個設計模式。
拿指令模式來說吧，我們開發中，請求-回應模式的功能非常常見，一般來說，我們會把對請求的回應操作封裝到一個方法中，這個封裝的方法可以稱之為命令，但不是命令模式。到底要不要把這種設計上升到模式的高度就要另行考慮了，因為，如果使用命令模式，就要引入調用者、接收者兩個角色，原本放在一處的邏輯分散到了三個類中，設計時，必須考慮這樣的代價是否值得。
以上是Java設計模式中關於命令模式的實例講解的詳細內容。更多資訊請關注PHP中文網其他相關文章！
