這幾天公司裏組織設計模式的學習,首先我非常贊同,這樣的做法,我們公司不僅僅是創造價值的公司,更是培養人才的公司.記得之前我們經常說的世界上有三類公司,第一類是做標準的公司,第二類是做產品的公司,第三類是做外包的公司.我想說的是,我們不僅僅想要做標準,我們更重要的是培養人才!這也是我從日本公司經營理念感悟到的.好了,廢話不多說了,這次設計模式,我有幸成爲演講者.團隊給了我很大的幫助,在此再次謝謝我的團隊和我的兄弟姐妹們.我們的頭,每年讓我們組織這種形式的學習,真是爲了實踐建構主義教學理念,孜孜不倦!很感謝我們的頭,少了他世界就少了一個演奏建構主義的音旋的世界性大師!我認爲人生的意義就在於此,當你離開人間邁進天堂的時候,請問百年之後,有誰還能說出你的事蹟,這就是人生的長度和質量!忠於國家,忠於人民,讓社會因有你而多了陽光和能量!自此,我的感受真的說完了!命令模式講課正式開始!
講課的重點就是這張圖,首先我用一句話概括了命令模式的特點（Invoker）通過(Command)把行爲抽象成一個個的對象，來實現請求者和執行者分離的目的。如何理解這句話，來看圖：
之前的圖是這樣的：
這兩張圖的不同點就在：（Invoker）（Command）（ConcreteCommand）這三個類以及類的關係上。之前通過調研，我瞭解大家的關注點在：（Invoker）這裏，其實命令模式的關鍵在於：（Command）
爲什麼這麼說：
有了抽象命令，纔有了封裝行爲的子類，（Invoker）的作用不小，但它發出的是命令，並不是執行者，真正的執行者還是（Receiver），這樣是抽象命令把請求者和執行者分離開了。或者說是服務員的發出的命令實現了二者的分離！
這樣的講解，大家沒有提出有價值的問題。不知道問題何在，然後我們就進行代碼和圖的對應的講解，沒想到問題出現在這裏！下面是代碼：
這是Clienk:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Command
{
class Program
{
static void Main(string[] args)
{
//實例化接收者和具體的命令
Receiver r = new Receiver();
Command a = new ConcreteCommandBakeMutton(r);
Command c = new ConcreteCommandBakeChickenWing(r);
Command b = new ConcreteCommandBakeChickenWing(r);
//實例化發出者
Invoker i = new Invoker();
//通過記錄命令和執行命令來完成請求
i.SetCommand(c);
i.ExecuteCommand();
i.SetCommand(b);
i.ExecuteCommand();
i.SetCommand(a);
i.ExecuteCommand();
Console.Read();
}
}
}
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Command
{
class Invoker
{
private Command command;
//接收記錄菜單
public void SetCommand(Command command)
{
this.command = command;
}
//執行命令
public void ExecuteCommand()
{
command.Execute();
}
//這裏可以通過取消命令的方法實現撤銷類似的功能！
}
}
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Command
{
//抽象的Command，用來讓子類繼承並實現裏面具體的方法
abstract class Command
{
protected Receiver receiver;
public Command(Receiver receiver)
{
this.receiver = receiver;
}
//抽象的方法
abstract public void Execute();
}
}
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Command
{
class ConcreteCommandBakeChickenWing :Command
{
//繼承父類來實例化執行者類
public ConcreteCommandBakeChickenWing(Receiver receiver)
: base(receiver)
{ }
//執行者執行和此命令有關的方法，這樣就實現了把行爲封裝成對象的作用
public override void Execute()
{
receiver.BakeChickenWing();
}
//同樣可以封裝多個方法，這樣可以實現一組命令，實現宏命令！
}
}
Receiver類
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Command
{
//執行者類
class Receiver
{
//執行烤串的方法
public void BakeMutton()
{
Console.WriteLine("喫烤串！老子請！");
}
//執行烤雞翅的方法
public void BakeChickenWing()
{
Console.WriteLine("喫烤雞翅！老子請！");
}
}
}
講課過程中，大家沒有把圖和代碼對應上，我們以爲能對應上，就直接演示了代碼。這樣一來，我們講課出現了討論，凡事有利有弊，通過討論我們也明白了很多，發現了講課還有很大的提升空間。在這裏，希望讀者好好運行一下代碼，並與圖對應上，因爲你看到我的博客，就不是一名簡簡單單的碼農，你將是什麼，取決於你的行動。
我的重點還是這種圖上，通過講圖就能發現命令模式的優勢和不足，也能知道在什麼情況下使用這個模式。
好處：通過把行爲封裝成對象，可以很容易的實現增加新的命令。
既然能把一個命令封裝成對象，那麼如果你把多個命令封裝成對象，就實現了一組命令，也就是我們經常說的宏命令。
可以在同一時間多不同的行爲，就是上面的延伸！
總是一句廢話：解耦了，只有你明白爲什麼耦合這麼強，如何解的藕，在什麼條件下解耦，這句話纔不是廢話！
弊端：如果增加的新的命令很多，那麼這就是它的不足。
在什麼情況下用：就回到了上面怎樣不把解耦變成廢話的問題上了，小編自己總結的一句話，如果不合適大家積極拍板：一個類調用另一個類，或者多個類調用一個類的時候，調用的方法很多，容易變化，如果直接調用類的方法，這樣兩個類或者多個類耦合性很強，這種情況下就適合使用這種模式。當然，除了我說的，小編也總結了一下大家之言，分享一下，希望大家在讀懂兵書的時候，不要被兵書所累。
命令模式的優點
降低系統的耦合度。
新的命令可以很容易地加入到系統中。
可以比較容易地設計一個命令隊列和宏命令（組合命令）。
可以方便地實現對請求的Undo和Redo
命令模式的缺點
使用命令模式可能會導致某些系統有過多的具體命令類。因爲針對每一個命令都需要設計一個具體命令類，因此某些系統可能需要大量具體命令類，這將影響命令模式的使用。
好了，知識性的講解，就到這了，書不盡言，言不盡意。希望大家多多爲他人提供幫助，這樣你收穫性更大，接下來，我想和大家再次聊聊建構主義教育。敬請期待！