命令模式將請求封裝成物件，以便使用不同的請求、佇列或者日誌來引數化其他物件。命令模式也支援可撤銷的操作。使用者程式在使用的時候，只與該命令物件打交道，而不用與一類物件打交道，降低了耦合性，提高了程式設計的靈活性。
我們還是那資料庫操作為例
public
class dbinstance
public
void executedataset()
}
public
class sqlinstance : dbinstance
}
public
class oracleinstance : dbinstance
}
public
inte***ce command
public
class sqlcommand : command
public
void execute()
}
public
class oraclecommand : command
public
void execute()
}
public
class dbcontrol
public
void setcommand(
int index,command comm)
public
void control(
int index)
} 測試下命令模式
總結：有的同學可能會問接收者有必要存在嗎？為何命令物件不知想實現execute（）方法的細節。一般來說，我們設計命令物件，它或許只需要呼叫乙個接收者的乙個行為。然而有許多命令物件會實現許多邏輯，直接完成乙個請求。當然你可以設計更全面的命令物件，只是這樣一來，呼叫者和接收者之間的解耦程度會再度降低。實際專案中命令可以將運算快打包（乙個接收者一組動作），然後將他們傳來傳去，就像是普通物件一樣。所以在日程安排、執行緒池、事務佇列中命令模式的使用也是比較廣泛的，
結合專案例項 回顧傳統設計模式（三）裝飾者模式
說到這個模式的專案例項 蟲子也滿頭疼的 所謂裝飾者模式說白了動態將職責附加到物件上。如果你在專案某個場景中需要功能擴充套件根據基類衍生出非常多的子類，那麼裝飾者模式無疑是很好的。不過其實在實際的專案中，往往大家不直接衍生子類，而是通過組合的方式，根據邏輯講各種擴充套件疊加來，對外公布的只是乙個標籤乙...
結合專案例項 回顧傳統設計模式（二）觀察者模式
觀察者模式現在用的不是很多 重點看下它的設計思想 ok 下面繼續 訊息中心的那點事 資料中心 public class messagedata 上述情況在soa體系架構中凸顯比較嚴重，基本上資料中心作為基站程式不適合版本經常更新 那麼這和一對多得關係有何關聯 利用觀察者模式，資料中心是具體狀態的物件...
結合專案例項 回顧傳統設計模式（二）觀察者模式
觀察者模式現在用的不是很多 重點看下它的設計思想 ok 下面繼續 訊息中心的那點事 資料中心 public class messagedata 上述情況在soa體系架構中凸顯比較嚴重，基本上資料中心作為基站程式不適合版本經常更新 那麼這和一對多得關係有何關聯 利用觀察者模式，資料中心是具體狀態的物件...