亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

23種設計模式(10):命令模式

系統 1931 0

文章來源: http://blog.csdn.net/zhengzhb/article/details/7550895

定義: 將一個請求封裝成一個對象,從而讓你使用不同的請求把客戶端參數化,對請求排隊或者記錄請求日志,可以提供命令的撤銷和恢復功能。

類型: 行為類模式

類圖:

23種設計模式(10):命令模式

命令模式的結構

顧名思義,命令模式就是對命令的封裝,首先來看一下命令模式類圖中的基本結構:

  • Command類: 是一個抽象類,類中對需要執行的命令進行聲明,一般來說要對外公布一個execute方法用來執行命令。
  • ConcreteCommand類: Command類的實現類,對抽象類中聲明的方法進行實現。
  • Client類: 最終的客戶端調用類。

以上三個類的作用應該是比較好理解的,下面我們重點說一下Invoker類和Recevier類。

  • Invoker類: 調用者,負責調用命令。
  • Receiver類: 接收者,負責接收命令并且執行命令。

所謂對命令的封裝,說白了,無非就是把一系列的操作寫到一個方法中,然后供客戶端調用就行了,反映到類圖上,只需要一個ConcreteCommand類和Client類就可以完成對命令的封裝,即使再進一步,為了增加靈活性,可以再增加一個Command類進行適當地抽象,這個調用者和接收者到底是什么作用呢?

其實大家可以換一個角度去想:假如僅僅是簡單地把一些操作封裝起來作為一條命令供別人調用,怎么能稱為一種模式呢?命令模式作為一種行為類模式,首先要做到低耦合,耦合度低了才能提高靈活性,而加入調用者和接收者兩個角色的目的也正是為此。命令模式的通用代碼如下:

  1. class Invoker{
  2. private Commandcommand;
  3. public void setCommand(Commandcommand){
  4. this .command=command;
  5. }
  6. public void action(){
  7. this .command.execute();
  8. }
  9. }
  10. abstract class Command{
  11. public abstract void execute();
  12. }
  13. class ConcreteCommand extends Command{
  14. private Receiverreceiver;
  15. public ConcreteCommand(Receiverreceiver){
  16. this .receiver=receiver;
  17. }
  18. public void execute(){
  19. this .receiver.doSomething();
  20. }
  21. }
  22. class Receiver{
  23. public void doSomething(){
  24. System.out.println( "接受者-業務邏輯處理" );
  25. }
  26. }
  27. public class Client{
  28. public static void main(String[]args){
  29. Receiverreceiver= new Receiver();
  30. Commandcommand= new ConcreteCommand(receiver);
  31. //客戶端直接執行具體命令方式(此方式與類圖相符)
  32. command.execute();
  33. //客戶端通過調用者來執行命令
  34. Invokerinvoker= new Invoker();
  35. invoker.setCommand(command);
  36. invoker.action();
  37. }
  38. }

通過代碼我們可以看到,當我們調用時,執行的時序首先是調用者類,然后是命令類,最后是接收者類。也就是說一條命令的執行被分成了三步,它的耦合度要比把所有的操作都封裝到一個類中要低的多,而這也正是命令模式的精髓所在:把命令的調用者與執行者分開,使雙方不必關心對方是如何操作的。

命令模式的優缺點

首先,命令模式的封裝性很好:每個命令都被封裝起來,對于客戶端來說,需要什么功能就去調用相應的命令,而無需知道命令具體是怎么執行的。比如有一組文件操作的命令:新建文件、復制文件、刪除文件。如果把這三個操作都封裝成一個命令類,客戶端只需要知道有這三個命令類即可,至于命令類中封裝好的邏輯,客戶端則無需知道。

其次,命令模式的擴展性很好,在命令模式中,在接收者類中一般會對操作進行最基本的封裝,命令類則通過對這些基本的操作進行二次封裝,當增加新命令的時候,對命令類的編寫一般不是從零開始的,有大量的接收者類可供調用,也有大量的命令類可供調用,代碼的復用性很好。比如,文件的操作中,我們需要增加一個剪切文件的命令,則只需要把復制文件和刪除文件這兩個命令組合一下就行了,非常方便。

最后說一下命令模式的缺點,那就是命令如果很多,開發起來就要頭疼了。特別是很多簡單的命令,實現起來就幾行代碼的事,而使用命令模式的話,不用管命令多簡單,都需要寫一個命令類來封裝。

命令模式的適用場景

對于大多數請求-響應模式的功能,比較適合使用命令模式,正如命令模式定義說的那樣,命令模式對實現記錄日志、撤銷操作等功能比較方便。

總結

對于一個場合到底用不用模式,這對所有的開發人員來說都是一個很糾結的問題。有時候,因為預見到需求上會發生的某些變化,為了系統的靈活性和可擴展性而使用了某種設計模式,但這個預見的需求偏偏沒有,相反,沒預見到的需求倒是來了不少,導致在修改代碼的時候,使用的設計模式反而起了相反的作用,以至于整個項目組怨聲載道。這樣的例子,我相信每個程序設計者都遇到過。所以,基于敏捷開發的原則,我們在設計程序的時候,如果按照目前的需求,不使用某種模式也能很好地解決,那么我們就不要引入它,因為要引入一種設計模式并不困難,我們大可以在真正需要用到的時候再對系統進行一下,引入這個設計模式。

拿命令模式來說吧,我們開發中,請求-響應模式的功能非常常見,一般來說,我們會把對請求的響應操作封裝到一個方法中,這個封裝的方法可以稱之為命令,但不是命令模式。到底要不要把這種設計上升到模式的高度就要另行考慮了,因為,如果使用命令模式,就要引入調用者、接收者兩個角色,原本放在一處的邏輯分散到了三個類中,設計時,必須考慮這樣的代價是否值得。

文章來源: http://blog.csdn.net/zhengzhb/article/details/7550895

定義: 將一個請求封裝成一個對象,從而讓你使用不同的請求把客戶端參數化,對請求排隊或者記錄請求日志,可以提供命令的撤銷和恢復功能。

類型: 行為類模式

類圖:

23種設計模式(10):命令模式

命令模式的結構

顧名思義,命令模式就是對命令的封裝,首先來看一下命令模式類圖中的基本結構:

  • Command類: 是一個抽象類,類中對需要執行的命令進行聲明,一般來說要對外公布一個execute方法用來執行命令。
  • ConcreteCommand類: Command類的實現類,對抽象類中聲明的方法進行實現。
  • Client類: 最終的客戶端調用類。

以上三個類的作用應該是比較好理解的,下面我們重點說一下Invoker類和Recevier類。

  • Invoker類: 調用者,負責調用命令。
  • Receiver類: 接收者,負責接收命令并且執行命令。

所謂對命令的封裝,說白了,無非就是把一系列的操作寫到一個方法中,然后供客戶端調用就行了,反映到類圖上,只需要一個ConcreteCommand類和Client類就可以完成對命令的封裝,即使再進一步,為了增加靈活性,可以再增加一個Command類進行適當地抽象,這個調用者和接收者到底是什么作用呢?

其實大家可以換一個角度去想:假如僅僅是簡單地把一些操作封裝起來作為一條命令供別人調用,怎么能稱為一種模式呢?命令模式作為一種行為類模式,首先要做到低耦合,耦合度低了才能提高靈活性,而加入調用者和接收者兩個角色的目的也正是為此。命令模式的通用代碼如下:

  1. class Invoker{
  2. private Commandcommand;
  3. public void setCommand(Commandcommand){
  4. this .command=command;
  5. }
  6. public void action(){
  7. this .command.execute();
  8. }
  9. }
  10. abstract class Command{
  11. public abstract void execute();
  12. }
  13. class ConcreteCommand extends Command{
  14. private Receiverreceiver;
  15. public ConcreteCommand(Receiverreceiver){
  16. this .receiver=receiver;
  17. }
  18. public void execute(){
  19. this .receiver.doSomething();
  20. }
  21. }
  22. class Receiver{
  23. public void doSomething(){
  24. System.out.println( "接受者-業務邏輯處理" );
  25. }
  26. }
  27. public class Client{
  28. public static void main(String[]args){
  29. Receiverreceiver= new Receiver();
  30. Commandcommand= new ConcreteCommand(receiver);
  31. //客戶端直接執行具體命令方式(此方式與類圖相符)
  32. command.execute();
  33. //客戶端通過調用者來執行命令
  34. Invokerinvoker= new Invoker();
  35. invoker.setCommand(command);
  36. invoker.action();
  37. }
  38. }

通過代碼我們可以看到,當我們調用時,執行的時序首先是調用者類,然后是命令類,最后是接收者類。也就是說一條命令的執行被分成了三步,它的耦合度要比把所有的操作都封裝到一個類中要低的多,而這也正是命令模式的精髓所在:把命令的調用者與執行者分開,使雙方不必關心對方是如何操作的。

命令模式的優缺點

首先,命令模式的封裝性很好:每個命令都被封裝起來,對于客戶端來說,需要什么功能就去調用相應的命令,而無需知道命令具體是怎么執行的。比如有一組文件操作的命令:新建文件、復制文件、刪除文件。如果把這三個操作都封裝成一個命令類,客戶端只需要知道有這三個命令類即可,至于命令類中封裝好的邏輯,客戶端則無需知道。

其次,命令模式的擴展性很好,在命令模式中,在接收者類中一般會對操作進行最基本的封裝,命令類則通過對這些基本的操作進行二次封裝,當增加新命令的時候,對命令類的編寫一般不是從零開始的,有大量的接收者類可供調用,也有大量的命令類可供調用,代碼的復用性很好。比如,文件的操作中,我們需要增加一個剪切文件的命令,則只需要把復制文件和刪除文件這兩個命令組合一下就行了,非常方便。

最后說一下命令模式的缺點,那就是命令如果很多,開發起來就要頭疼了。特別是很多簡單的命令,實現起來就幾行代碼的事,而使用命令模式的話,不用管命令多簡單,都需要寫一個命令類來封裝。

命令模式的適用場景

對于大多數請求-響應模式的功能,比較適合使用命令模式,正如命令模式定義說的那樣,命令模式對實現記錄日志、撤銷操作等功能比較方便。

總結

對于一個場合到底用不用模式,這對所有的開發人員來說都是一個很糾結的問題。有時候,因為預見到需求上會發生的某些變化,為了系統的靈活性和可擴展性而使用了某種設計模式,但這個預見的需求偏偏沒有,相反,沒預見到的需求倒是來了不少,導致在修改代碼的時候,使用的設計模式反而起了相反的作用,以至于整個項目組怨聲載道。這樣的例子,我相信每個程序設計者都遇到過。所以,基于敏捷開發的原則,我們在設計程序的時候,如果按照目前的需求,不使用某種模式也能很好地解決,那么我們就不要引入它,因為要引入一種設計模式并不困難,我們大可以在真正需要用到的時候再對系統進行一下,引入這個設計模式。

拿命令模式來說吧,我們開發中,請求-響應模式的功能非常常見,一般來說,我們會把對請求的響應操作封裝到一個方法中,這個封裝的方法可以稱之為命令,但不是命令模式。到底要不要把這種設計上升到模式的高度就要另行考慮了,因為,如果使用命令模式,就要引入調用者、接收者兩個角色,原本放在一處的邏輯分散到了三個類中,設計時,必須考慮這樣的代價是否值得。

23種設計模式(10):命令模式


更多文章、技術交流、商務合作、聯系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯系: 360901061

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 毛片免费观看久久欧美 | 99热这就是里面只有精品 | 亚洲国产成人久久一区www妖精 | 性色视频| 国产911情侣拍拍在线播放 | 桃花综合 | 99re6在线视频免费精品 | 亚洲精品久中文字幕 | 日韩高清在线二区 | 国产亚洲精品看片在线观看 | 亚洲特级aaaaaa毛片 | 国内精品久久久久久久亚洲 | 四虎影院永久免费 | 国产女人伦码一区二区三区不卡 | jizjizjiz亚洲大全 | 无遮挡一级毛片性视频不卡 | 国产精品久久久久久爽爽爽 | 香蕉成人啪国产精品视频综合网 | 亚洲国产清纯 | 亚洲综合中文网 | 亚洲一区日韩 | 波多野结衣亚洲 | 外国一级黄色毛片 | 国产亚洲精品激情都市 | 国产亚洲免费观看 | 九九九精品在线观看 | 欧美精品综合一区二区三区 | 12345国产精品高清在线 | 春色www在线视频观看 | 精品国产亚洲一区二区三区 | 亚洲 欧美 国产另类首页 | 黄色成人在线网站 | 日本一区二区网站 | 午夜时刻免费实验区观看 | 图片专区亚洲 欧美 另类 | 久久国产精品一国产精品金尊 | 香蕉久久精品国产 | 99久久免费看精品国产一区 | 青青草国产三级精品三级 | 国产免费久久精品丫丫 | 狠狠综合久久久久综合小说网 |