早上看.net framework 3.5的分部方法這個特性。例子如下，第一個類為定義類，第二、第三個類為實現類。

 AI
    

{
        publicvoid Active()
        {
            this.Run();
            this.Jump(); 
         }
 
        partial void Run();
 
        partial void Jump();
     }

 
    

 AI
    

{
        partial void Run()

        {
            Console.WriteLine("我在跑");
        }
    }

 
    

 AI
    

{
        partial void Jump()
        {
            Console.WriteLine("我在跳");
        }
    }

它可以:

1. 以上三個類可以不放在相同的CS檔案裡

2. 後兩個分部類如果不寫，編譯能順利通過，在IL裡產生有方法體的Run和Jump，但是空實現。

它不可以：

1．分部方法不能是公開型別，必須是私有。

2．實現類不能和定義類分別存在不同的程式集裡。

它有價值的地方：

1．更細化分工過程。以前系統分析到物件級，現在可以細到方法級別。從例子裡看，物件框架維護人定義了Active方法，而Run和Jump可能被分派到其他人實現。

這樣的分工模式和更大規模的整合開發趨勢是緊密關聯的。簡單的看，這只是一個新的語言特性；仔細思考，這其實是軟體朝工業化方向發展的一個訊號。以後的軟體開發過程勢必是基於更多特性（或者說是開發工藝），在生產線上完成的。一個人就是一個螺絲釘，讓你實現Run就Run，讓你Jump就Jump，如果你想發揮自己的聰明才智，好，就在這個範圍內盡情的發揮吧！

 2．程式碼可以寫的更優雅，如果本例中的Run和Jump的內部實現異常複雜（AI機器人行為嘛），一個CS

 3. 程式碼優雅只是一個表象，如果是犧牲了效能換取的，我寧願不要這個特性。事實上恰恰相反，分部方法的效率是非常OK的。具體就去寫個例子，觀察IL吧。哈哈！