為了避免繁瑣的轉(zhuǎn)型，為了獲得類型安全的各種優(yōu)勢，我們也可以選擇為每種不同的消息創(chuàng)建獨立的類型。不過由于一個Actor往往會應(yīng)對各種消息，因此在.NET環(huán)境中，往往我們需要把消息類型定義為object。如果使用ActorLite來演示的話，代碼可能是這樣的：

ActorLite的演示

class Person : Actor<object>  
{  
    protected override void Receive(object message)  
    {  
        if (message is ChatMessage)  
        {  
            ChatMessage chatMsg = (ChatMessage)message;  
            Person another = chatMsg.Another;  
            Topic topic = chatMsg.Topic;  
            // ...  
        }  
        else if (message is EatMessage)  
        {  
            EatMessage eatMsg = (EatMessage)message;  
            Restaurant restaurant = eatMsg.Restaurant;  
            // ...  
        }  
        else if (message is WorkMessage)  
        {  
            WorkMessage workMsg = (WorkMessage)message;  
            Person reportTo = workMsg.ReportTo;  
            Job job = workMsg.Job;  
            // ...  
        }  
    }  
} 

圖示如下：

在Actorlite演示中，使用if…else來進行邏輯分支判斷還是必要的，不過我們這里使用了靜態(tài)類型代替了Magic String（當(dāng)然在使用Tag Message時也可以使用常量）的判斷，同時危險而麻煩的類型轉(zhuǎn)換操作也減少的。與Tag Message相比，這種做法獲得了一定的類型安全優(yōu)勢，可以得到編譯器的靜態(tài)檢查，做起重構(gòu)來也有了依據(jù)。不過他也有比較明顯的缺陷，那就是需要構(gòu)建大量的消息類型。要知道消息類型的數(shù)量很可能是Actor類型數(shù)量的幾倍，每種消息類型還包含著多個屬性，構(gòu)造函數(shù)接受參數(shù)，然后在構(gòu)造函數(shù)里設(shè)置屬性……這種做法對復(fù)雜性的提升還是較為可觀的，有時候會感覺還不如使用簡單的Tag Message。

【編輯推薦】

1. C#的Tag Message回顧：繁瑣而危險
2. Erlang的Actor回顧：將消息轉(zhuǎn)化為邏輯執(zhí)行
3. Actor模型的本質(zhì)：究竟是要解決什么問題
4. 順暢的使用C# Actor：另一個解決方案
5. C# Actor的尷尬與F#美麗外表下的遺憾