您好,登錄后才能下訂單哦!
本篇內容主要講解“如何理解Java設計模式的命令模式”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“如何理解Java設計模式的命令模式”吧!
命令模式是一個高內聚的模式,其定義為:將一個請求封裝成一個對象,從而讓你使用不同的請求把客戶端參數化,對請 求排隊或者記錄請求日志,可以提供命令的撤銷和恢復功能。
在該類圖中,我們看到三個角色:
Receiver
接受者角色:該角色就是干活的角色,命令傳遞到這里是應該被執行的
Command
命令角色:需要執行的所有命令都在這里聲明
Invoker
調用者角色:接收到命令,并執行命令
使用時機:當需要先將一個函數登記上,然后再以后調用此函數時,就需要使用命令模式,其實這就是回調函數。
有時候需要向某些對象發送請求,但是并不知道請求的接收者是誰,也不知道被請求的操作是什么。此時希望用一種松耦合的方式來設計程序,使得請求發送者和請求接收者能夠消除彼此之間的耦合關系
例子:拿訂餐來說,客人需要向廚師發送請求,但是完全不知道這些廚師的名字和聯系方式,也不知道廚師炒菜的方式和步驟。 命令模式把客人訂餐的請求封裝成 command 對象,也就是訂餐中的訂單對象。這個對象可以在程序中被四處傳遞,就像訂單可以從服務員手中傳到廚師的手中。這樣一來,客人不需要知道廚師的名字,從而解開了請求調用者和請求接收者之間的耦合關系
優點:
類間解耦:調用者角色與接收者角色之間沒有任何依賴關系,調用者實現功能時只需調用Command 抽象類的execute方法就可以,不需要了解到底是哪個接收者執行。可擴展性:Command的子類可以非常容易地擴展,而調用者Invoker和高層次的模塊Client不產生嚴 重的代碼耦合。命令模式結合其他模式會更優秀:命令模式可以結合責任鏈模式,實現命令族解析任務;結合模板方法模式,則可以減少 Command子類的膨脹問題。
缺點:
命令模式也是有缺點的,請看Command的子類:如果有N個命令,問題就出來 了,Command的子類就可不是幾個,而是N個,這個類膨脹得非常大,這個就需要讀者在項 目中慎重考慮使用。
Receiver
類,知道如何實施與執行一個與請求相關的操作,任何類都可能作為一個接受者
class Receiver { public void Action() { Console.WriteLine("執行請求!"); } }
Command
類,用來聲明執行操作的接口
abstract class Command { protected Receiver receiver; public Command(Receiver receiver) { this.receiver = receiver; } abstract public void Execute(); }
ConcreteCommand
類,將一個接受者對象綁定于一個動作,調用接受者相應的操作,以實現Execute。
class ConcreteCommand : Command { public ConcreteCommand(Receiver receiver) : base(receiver) { } public override void Execute() { receiver.Action(); } }
Invoker
類,要求該命令執行這個請求
class Invoker { private Command command; public void SetCommand(Command command) { this.command = command; } public void ExecuteCommand() { command.Execute(); } }
客戶端代碼
static void Main(string[] args) { Receiver r = new Receiver(); Command c = new ConcreteCommand(r); Invoker i = new Invoker(); i.SetCommand(c); i.ExecuteCommand(); Console.Read(); }
到此,相信大家對“如何理解Java設計模式的命令模式”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。