在前兩篇文章中，我們了解到Erlang中靈活的模式匹配，以及在C#甚至F#中會都遭遇的尷尬局面。那么現在就應該來設計一個解決方案了，我們如何才能在C#這樣的語言里順暢地使用Actor模型呢？不僅如此，***我們還能獲得其它一些優勢。

C# Actor：“消息”、“協議”和“接口”
Actor模型中的對象如果要進行交互，唯一的手段便是發送消息。不同語言/平臺上的消息有不同的表現形式，但是它們所傳遞的信息是一致的：
◆做什么事情
◆做這件事情需要的數據

例如，Erlang中往往會使用Tag Message的格式作為消息：

{doSomething, Arg1, Arg2, Arg3, ...} 

其中，原子doSomthing表示“做什么”，而后面的ArgN便是一個個的參數，使用Erlang中的模式匹配可以很方便地捕獲消息中的數據。在C#等語言中，由于并非專為了Actor模型設計，因此一個Message往往只能是一個對象。但是這個對象的職責并沒有減輕，因此我們需要自己處理的事情就多了。我們可能會這樣做：

學Erlang的Tag Message，但是這樣會產生大量丑陋的類型轉換操作，并且喪失了靜態檢查功能。
為每種消息創建不同的Message類型，但是這樣會產生大量類類型，每個類型又有各種屬性，非常麻煩。
這兩種做法在上一篇文章里都有過討論，感興趣的朋友可以再去“回味”一番。那么，究竟什么是消息呢？根據我的理解，“消息”其實是這么一種東西：
◆“消息”表示“發送方”和“接受方”之間的“通信協議”（例如Erlang中的“模式”）。
◆“消息”表示“發送方”要“接受方”所做的事情，但是并沒有要求“接受方”需要怎么做。
◆一個Actor可能會會作為“接受方”遵守多種“通信協議”。

經過這樣的描述，您是否覺得.NET中有一種東西和“消息”非常接近？沒錯，那就是“接口”，因為：
◆“接口”從概念上講便是一種“協議”。
◆“接口”表示“能做什么”，但沒有限制“怎么做”。
◆一個Actor可以實現多個接口，即遵守多種協議。

看上去還真是一一對應??！那么我們再來深入一步進行對比，“接口”能否傳遞消息所要表現的信息？答案也是肯定的：
◆做什么事情：接口中的一個方法。
◆需要的數據：接口的參數。

也就是說，如之前的那條Erlang消息，在C#中便可以表示為：

x.DoSomething(arg1, arg2, arg3, ...) 

基于這樣的類比，我們發現使用“接口”還可以帶來一個額外的東西，那就是“消息組”。如Erlang這樣語言，消息與消息之間是完全獨立的。.NET中的接口可以包含多個方法，這就是一種“分組”，我們可以利用這種方式來更好地管理有關聯的消息。此外，利用.NET中的訪問限制符（public，internal等）還可以實現消息的公開和隱藏。而且因為接口的參數是強類型的，所以可以得到編譯期的檢查，也可以享受編輯工具的代碼提示及重構……C#編程里的種種優勢似乎我們一個都沒有拉下。

C# Actor看似美好的實現
等一下，接口只是一種“協議”，但是“消息”還必須是一個實體，一個對象，并且“攜帶”了這個協議才能在Actor之間傳遞埃這個對象除了攜帶協議所需要的數據以外，還要能夠告訴接受方究竟該“操作什么”?！安僮鳌睅稀皵祿?，于是我就想到了“委托”。例如，如果我們想要發送一個“協議”，叫做IDoHandler，那么我們便可以構造一個Action﹤IDoHandler>對象——這正是Lambda表達式的用武之地：

Action﹤IDoHandler> m = x => x.Do(0, 1, 2, ...); 

好，那么我們還是用乒乓測試來嘗試一番。我們知道，乒乓測試會讓Ping對象和Pong對象相互發送消息，我們各使用一個“消息組”，也就是“接口”來定義消息：

public interface IPongMessageHandler { }  
 
public interface IPingMessageHandler { }  

那么，Ping和Pong兩個Actor類型又該如何定義呢？我們知道，Ping需要處理Pong發來的消息，因此它需要實現IPongMessageHandler接口，并且需要接受類型為Action﹤IPongMessageHandler>的消息。Pong與Ping類似，因此它們的定義為：

public class Ping : Actor﹤Action﹤IPongMessageHandler>>, IPongMessageHandler  
{  
    private int m_count;  
 
    public Ping(int count)  
    {  
        this.m_count = count;  
    }  
 
    protected override void Receive(Action﹤IPongMessageHandler> message)  
    {  
        message(this);  
    }  
 
    ...  
}  
 
public class Pong : Actor﹤Action﹤IPingMessageHandler>>, IPingMessageHandler  
{  
    protected override void Receive(Action﹤IPingMessageHandler> message)  
    {  
        message(this);  
    }  
 
    ...  
}  

從代碼上看，實際操作中我們并不需要讓Ping或Pong直接繼承Handler接口，只要最終提供一個對象給message執行即可。嚴格說來，“接口”只是一個“消息組”，具體的“消息”還是要落實到接口中的方法。定義了Ping和Pong之后，我們便可以明確接口中的方法了（確切地說，是明確了方法的參數）：

public interface IPongMessageHandler  
{  
    void Pong(Pong pong);  
}  
 
public interface IPingMessageHandler  
{  
    void Ping(Ping ping);  
    void Finish();  
}  

使用了接口，自然就要提供方法的實現了。我們先從典型而簡單的Pong對象看起：

public class Pong : Actor﹤Action﹤IPingMessageHandler>>, IPingMessageHandler  
{  
    ...  
 
    #region IPingMessageHandler Members  
 
    void IPingMessageHandler.Ping(Ping ping)  
    {  
        Console.WriteLine("Pong received ping");  
        ping.Post(h => h.Pong(this));  
    }  
 
    void IPingMessageHandler.Finish()  
    {  
        Console.WriteLine("Finished");  
        this.Exit();  
    }  
 
    #endregion  
}  

原本需要在得到消息之后，根據消息的內容作出不同的響應。而現在，消息會被自動轉發為接口中的方法調用，我們只需要實現特定的方法即可。在Ping方法中，我們會得到一個Ping類型的對象——于是我們再向它回復一個消息。消息的類型是Action﹤IPongMessageHandler>，可以看出，使用Lambda表達式構造這樣一個消息特別方便。

Ping類也只需要實現IPongMessageHandler即可，只是這段邏輯“略顯復雜”：

public class Ping : Actor﹤Action﹤IPongMessageHandler>>, IPongMessageHandler  
{  
    ...  
 
    public void Start(Pong pong)  
    {  
        pong.Post(h => h.Ping(this));  
    }  
 
    #region IPongMessageHandler Members  
 
    void IPongMessageHandler.Pong(Pong pong)  
    {  
        Console.WriteLine("Ping received pong");  
 
        if (--this.m_count > 0)  
        {  
            pong.Post(h => h.Ping(this));  
        }  
        else 
        {  
            pong.Post(h => h.Finish());  
            this.Exit();  
        }  
    }  
 
    #endregion  
}  

收到Pong消息之后，將count減1，如果還大于0，則回復一個Ping消息，否則就回復一個Finish并退出。***啟動乒乓測試：

new Ping(5).Start(new Pong());由于使用了接口作為消息的協議，因此無論是編輯器還是編譯器都可以給我們足夠的支持。同時，對于消息的處理也無須如上一篇文章那樣不斷進行判斷和類型轉換，代碼可謂流暢不少。

C# Actor致命的缺陷
雖說沒有***的東西，但目前的缺陷卻是致命的。

在實際使用過程中，消息的“發送方”和消息的“接收方”應該完全無關，它們互不知道對方具體是誰，只應該基于“協議”，也就是“接口”來實現?？上г谏厦孢@段代碼中，很多東西都被“強橫”地限制住了。例如，Ping消息會附帶一個ping對象作為參數，ping對象會等待一個Pong消息。但是，發送Ping消息（并等待Pong消息）的一方很可能是各種類型的Actor，不一定是Ping類型。有朋友可能會說，那么我們把IPingMessageHandler的Ping方法的簽名改成這樣，不就可以了嗎？

void Ping(Actor﹤Action﹤IPongMessageHandler>> ping) 

是的，此時的ping，的確是在“等待Pong消息的Actor對象”。但是，這意味著ping對象它也只能是這個指明的Actor類型了。在實際使用過程中，這幾乎是不可能的事情。因為一個Actor很可能會接受各種消息，它很難做到“一心一意”。因此這篇文章所提出的做法，幾乎只能滿足如乒乓測試這樣簡單的Actor模型使用場景。我們必須改變。

改變的方式有不少，從“向弱類型妥協”到“利用.NET 4.0中的協變/逆變”，都可以滿足不同的場景——不過我們還是下次再說吧。

F#的實現
本文描述的方式也可以運用在在F#中。首先自然還是接口的定義：

type IPingMessageHandler =  
    abstract Ping : Ping -> unit  
    abstract Finish : unit -> unit  
 
and IPongMessageHandler =   
    abstract Pong : Pong -> unit  

以上便是F#中定義接口的方式，與C#相比更為簡潔。接著便是Ping類型的實現：

and Ping() =  
    inherit (IPongMessageHandler -> unit) Actor()  
    let mutable count = 5  
    override self.Receive(message) = message self  
 
    member self.Start(pong : Pong) =   
        pong ﹤﹤ fun h -> self |> h.Ping  
      
    interface IPongMessageHandler with   
        member self.Pong(pong) =  
            printfn "Ping received pong" 
            count ﹤- count - 1  
            if (count > 0) then  
                pong ﹤﹤ fun h -> self |> h.Ping  
            else 
                pong ﹤﹤ fun h -> h.Finish()  
                self.Exit()Pong類型的實現則更為簡單：  
 
and Pong() =  
    inherit (IPingMessageHandler -> unit) Actor()  
    override self.Receive(message) = message self  
      
    interface IPingMessageHandler with  
        member self.Ping(ping) =  
            printfn "Pong received ping" 
            ping ﹤﹤ fun h -> self |> h.Pong  
          
        member self.Finish() =  
            printfn "Finished" 
            self.Exit()啟動乒乓測試：  
 
(new Pong()) |> (new Ping()).Start;  
 

【編輯推薦】

1. C# Actor的尷尬與F#美麗外表下的遺憾
2. 看Erlang中Actor模型的執行方式和優劣
3. Erlang面向分布與并發的編程語言
4. Erlang十分鐘快速入門
5. 因并發而生 因云計算而熱：Erlang專家訪談實錄