為了避免繁瑣的轉型，為了獲得類型安全的各種優勢，我們也可以選擇為每種不同的消息創建獨立的類型。不過由于一個Actor往往會應對各種消息，因此在.NET環境中，往往我們需要把消息類型定義為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來進行邏輯分支判斷還是必要的，不過我們這里使用了靜態類型代替了Magic String（當然在使用Tag Message時也可以使用常量）的判斷，同時危險而麻煩的類型轉換操作也減少的。與Tag Message相比，這種做法獲得了一定的類型安全優勢，可以得到編譯器的靜態檢查，做起重構來也有了依據。不過他也有比較明顯的缺陷，那就是需要構建大量的消息類型。要知道消息類型的數量很可能是Actor類型數量的幾倍，每種消息類型還包含著多個屬性，構造函數接受參數，然后在構造函數里設置屬性……這種做法對復雜性的提升還是較為可觀的，有時候會感覺還不如使用簡單的Tag Message。

【編輯推薦】

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