1.指令模式是什麼
1.百度百科
指令模式（Command Pattern）是一種設計模式，它嘗試以物件來代表實際行動。
2.維基百科
In object-oriented programming, the command pattern is a behavioral design pattern in which an object is used to encapsulate all information needed to perform an action or trigger an event at a later time. This information includes the method name, the object that owns the method and values for the method parameters.
Four terms always associated with the command pattern are command, receiver, invoker and client. A command object knows about receiver and invokes a method of the receiver. Values for parameters of the receiver method are stored in the command, the receiver object to execute these methods is also stored in the command object by aggregation. The receiver then does the work when the execute() method in command is called. An invoker object knows how to execute a command, and optionally does bookkeeping about the command execution. The invoker does not know anything about a concrete command, it knows only about the command interface. Invoker object(s), command objects and receiver objects are held by a client object, the client decides which receiver objects it assigns to the command objects, and which commands it assigns to the invoker. The client decides which commands to execute at which points. To execute a command, it passes the command object to the invoker object.
3.lz了解
在調用者和被調用者中間增加一個對象,使用調用者對象允許記錄關于指令執行的便利，以及為由調用者對象管理的指令實作不同的模式，而不需要客戶意識到存在簿記或模式。
4.核心角色
抽象指令角色 (Command)：聲明執行操作的接口。調用接收者相應的操作。
具體指令角色（ConcreteCommand）：指令接口實作對象，是“虛”的實作；通常會持有接收者，并調用接收者的功能來完成指令要執行的操作。建立一個具體指令對象并設定它的接收者。通常會持有接收者，并調用接收者的功能來完成指令要執行的操作。
接收者角色（Receiver）：真正執行指令的對象。任何類都可能成為一個接收者，隻要它能夠實作指令要求實作的相應功能。知道如何實施與執行一個請求相關的操作。任何類都可能作為一個接收者,隻要它能夠實作指令要求實作的相應功能。
調用者角色（Invoker）：要求指令對象執行請求，通常會持有指令對象，可以持有很多的指令對象。這個是用戶端真正觸發指令并要求指令執行相應操作的地方，也就是說相當于使用指令對象的入口。 要求該指令執行這個請求。通常會持有指令對象，可以持有很多的指令對象。
2.指令模式解決了什麼問題
類間解耦：調用者角色與接收者角色之間沒有任何依賴關系，調用者實作功能時隻需調用Command 抽象類的execute方法就可以，不需要了解到底是哪個接收者執行。
可擴充性：Command的子類可以非常容易地擴充，而調用者Invoker和高層次的子產品Client不産生嚴 重的代碼耦合。
3.指令模式用法
業務人員提出需求，傳遞經理，經理從中協調将任務配置設定給程式員。
具體執行類，接收者角色。即具體處理功能的角色，也就是程式員。
/**
* 程式員接口 定義程式員能做的操作
* （Receiver）任務接收者
*/
public interface Programmer {
//編寫bug
void modifyBug(String bugs);
//添加需求
void addRequests(String reqs);
//編寫文檔
void writeDocument(String docs);
}
public class ProgrammerImpl implements Programmer {
@Override
public void modifyBug(String bugs) {
System.out.println("程式員改bugs:" + bugs);
}
@Override
public void addRequests(String reqs) {
System.out.println("程式員寫新需求:" + reqs);
}
@Override
public void writeDocument(String docs) {
System.out.println("程式員寫文檔:" + docs);
}
}
抽象指令角色和具體指令角色。也就是經理
/**
* 經理
*/
public interface ProductManager {
public void modifyBug(String bugs);
public void addRequests(String reqs);
public void writeDocument(String docs);
}
//具體産品經理
public class WangerProductManager implements ProductManager {
//程式員
private Programmer programmer;
public WangerProductManager() {
programmer = new ProgrammerImpl();
}
@Override
public void modifyBug(String bugs) {
programmer.modifyBug(bugs);
}
@Override
public void addRequests(String reqs) {
programmer.addRequests(reqs);
}
@Override
public void writeDocument(String docs) {
programmer.writeDocument(docs);
}
}
功能需求方，調用者角色。也就是業務人員、
//業務人員
public class BizPeople {
//産品經理
private ProductManager productManager;
public BizPeople(ProductManager productManager) {
this.productManager = productManager;
}
public void modifyBug(String bugs) {
this.productManager.modifyBug(bugs);
}
public void addRequests(String reqs) {
this.productManager.addRequests(reqs);
}
public void writeDocument(String docs) {
this.productManager.writeDocument(docs);
}
}
業務人員調用經理發出需求。
public class Client {
public static void main(String[] args) {
//業務人員找來産品經理
ProductManager productManager = new WangerProductManager();
BizPeople bizPeople = new BizPeople(productManager);
//給産品經理一個需求
bizPeople.addRequests("添加一個頁面");
}
}
4.指令模式的問題
指令角色膨脹：如果有N個指令，問題就出來 了，Command的子類就可不是幾個，而是N個，這個類膨脹得非常大，這個就需要讀者在項 目中慎重考慮使用。
具體指令類過多：用指令模式可能會導緻某些系統有過多的具體指令類。因為針對每一個指令都需要設計一個具體指令類，是以某些系統可能需要大量具體指令類，這将影響指令模式的使用。
5.指令模式總結
指令模式應用場景：
将指令發起者和指令執行者通過一層隔離開。
請求-響應這種功能非常常見，而請求和響應中間是否需要加入一個指令層确實需要考慮，增加一層封裝固然能使用項目耦合度降低，但是随之也帶來了複雜性。業務的分散也造成代碼難以了解。在面對是否要添加指令模式的時候還是那句話封裝變化以保證業務的拓展性。如果變化比較小或者沒有變化直接調用的方式可能比指令模式更加簡潔明晰。
http://blog.csdn.net/wwh578867817/article/details/51533263