再次感謝編輯大人 :D，Transactional NTFS  #2 也刊出來了!

這篇是延續上一篇，進一步的介紹 TxF  如何與 TransactionScope 互動，讓你可以結合檔案系統及資料庫的異動，變成單一交易的技巧。

由於TxF還沒有正式在.NET Framework裡支援，所以這篇最後也介紹了 AlphaFS，可以簡化應用時的障礙。AlphaFS 是一套想要取代 System.IO.* 的類別庫，它支援了許多 NTFS 的進階功能 (像是 VSS、HardLink 等) 的功能，而 TxF 也在範圍內，透過它就不用再像 上一篇 一樣，辛苦的用 P/Invoke 了。

這篇提到的範例程式可以在這裡下載。有任何意見也歡迎在這裡留話給我 :D

五月號就刊出來，還真有點意外 :D，這次稿件趕不及，晚了幾天才交出去，編輯大人還是讓我上五月號啦，真是感謝 :D

之前執行緒的系列，是打算把各種應用執行緒的演算法都介紹一下，寫了五篇就沒靈感了。實際寫CODE的技巧倒是很多可以介紹，不過 .NET FX 4.0 出來之後，這些鎖碎的 coding 技巧又大幅簡化了，除非有特別的演算法需要 (如同之前那五篇 :D)，否則還自己拿 Thread 物件硬幹已經沒什麼意義了，所以就換另一個我有興趣的主題 - Transactional NTFS 來寫。

這系列第一篇出爐了，主要就是先介紹它的觀念及如何入門，國內這類資訊還不多，我就野人獻曝寫了一篇，試著寫看看了。較鎖碎的實作技巧 (如 P/Invoke) 我會直接貼 BLOG，而較完整的概念及實作探討等等就會整理成文章拿來投稿了。

再次感謝各位支持啦，底下有範例程式跟一些參考資源的 LINK，需要的歡迎取用 :D

範例程式:

1. Visual Studio 2008 Project (C#) File: TransactionDemo.zip

參考資訊:

1. AlphaFS: Brining Advanced Windows FileSystem Support to .NET
   http://alphafs.codeplex.com/
2. MSDN magazine (July 2007): Enhance Your Apps With File System Transactions
   http://msdn.microsoft.com/en-us/magazine/cc163388.aspx
3. B# .NET BLOG: Windows Vista - Introducing TxF In C#
   Part 1: Transacted File Delete
   Part 2: Using System.Transactions and the DTC
   Part 3: CreateFileTransacted Demo
4. Code Project: Windows Vista TxF / TxR
   http://www.codeproject.com/KB/vista/KTM.aspx
5. BLOG: Because we can
   http://blogs.msdn.com/because_we_can/archive/2005/05/18/419809.aspx
   Discussion and explanation relating to the Transactional NTFS feature coming in Longhorn, plus any other interesting anecdotes...
6. Performance Consoderations for Transactional NTFS
   http://msdn.microsoft.com/en-us/library/ee240893(VS.85).aspx
7. When to Use Transactional NTFS
   http://msdn.microsoft.com/en-us/library/aa365738(VS.85).aspx

隔了足足一年，趁著過年，生出第五篇了 :D，再次感謝編輯賞光啦，願意刊登我寫的題材...

這篇 [生產者/消費者] 其實是延續上一篇 [生產線模式] 而來的，生產線模式，是利用 PIPE 的方式，把工作切成各個階段同時進行。而生產者消費者，則是去探討兩個階段之間如何做好進度的協調。這篇除了講講處理的原則之外，也實作了BlockQueue來簡化這個問題。

其實更漂亮的用法，是我在 MSDN Magazine 上看到的 BlockingStream, 直接把它作成 System.IO.Stream 的衍生類別。像那些包裝成 Stream 的資料處理 (像是壓縮、加密、或是 Socket 這類)，都很適合。不過一般情況下不是所有應用都能套上 Stream 的模式，因此就有了把它包裝成 Queue 的念頭，也就是這篇寫的 BlockQueue 的應用。

相關的東西其實過去也寫了幾篇，只不過 BLOG 寫的都比較瑣碎，都是針對特定主題較深入的討論，而投稿的文章就會比較完整的介紹原理及作法等等，細節就沒辦法兼顧了。有興趣的讀者可以參考一下我部落格的相關文章 :D   這期的範例程式可以在底下下載，相關的 LINK 也列在底下。

再次謝謝各位支持啦 :D

MSDN Magazine 閱讀心得: Stream Pipeline
RUN!PC 精選文章 - 生產線模式的多執行緒應用
[RUN! PC] 2008 十一月號 生產線模式的多執行緒應用
生產者 vs 消費者 - BlockQueue 實作

繼上一篇，介紹了如何用windows server内建的磁碟鏡像 (Mirror) 更換硬碟後，這次剛好有windows 2003，就拿來試了一下...

廢話就不多說了，先來看一下 2003 的步驟，再來看看跟 2008 / 2008R2 差在那裡:

1. 原本的樣子，磁碟1 (8.00GB) 是舊的硬碟，磁碟2 (16.00GB) 是要換上來的新硬碟:
   
   
   
2. 磁碟1 + 磁碟2 做成鏡像 (MIRROR):
   
   
   
   等待重新同步化 (Resync) 完成:
   
   
   
   
3. Resync 完成後，移除鏡像:
   
   
   
   移除鏡像完成後的狀態:
    
   
   
4. 用 2003 的延伸磁區，把磁碟2後面沒用到的空間也併進 D: 來
   
   
   
   合併之後的狀態:
    
   
   
   
   

整個步驟跟前一篇都差不多，主要都是靠鏡像(MIRROR)搬完資料後，再把新硬碟多的可用空間併進來。唯一的差別就在這裡: 2003 的 "延伸磁區" (英文: extend volume) 是可以把兩個硬碟，或是兩個分割區併在一起使用。在磁碟管理員還是看的到這些分割區的存在。這就有點像 JBOD (Just a Bunch Of Disks) 的模式。

不過在 2008 之後 (其實 vista 也是)，這個功能就改了。原本的名字 extend volumn 現在改成直接擴大原分割區，把原分割區後面可用的空間都納進來，就像你砍掉再重建一個大的分割區一樣，只是資料會留著不會掉。當然有 extend 也有相對的 shrink volume, 這功能會把分割區縮小，騰出空間來讓你多切一個分割區...。而原本 JBOD 模式的功能，則改為 span disk, 用起來效果就如上圖一樣，當然你願意的話，也可以把多顆硬碟 (可以不同容量) 通通併成一個來使用，最多可以併到 32 顆硬碟...。

沒經過這次更換硬碟，還真沒發現 2008 / vista 總算內建這組 extend / shrink volume 的功能進來。雖然很陽春，不過已經很實用了，在過去這種動作是得搬出像 partition magic 這類軟體才能做的到，而這種東西每次用起來心裡都會毛毛的，深怕一不小心就把資料都給毀了...。

這篇小品文章就記到這裡，希望有幫到需要的人 :D

老是寫一堆像外星文，沒人看的懂的 multi-threading 文章，偶爾也來換換口味吧。前陣子把 SERVER 的兩顆 750GB HDD (RAID1) 升級了一下，升級成兩顆 1.5TB HDD (RAID1)。更換硬碟是小事，不過這個硬碟上有些服務，如網站，資料庫，還有一些重要資料，跟分享資料夾，想一想要更換也是挺囉唆的...。

想了幾個辦法，不過都不符合我既懶又挑毛病的個性... 原本考慮的更換方式有:

1. 硬上... 新硬碟裝上去，檔案COPY過去，能停的服務就停掉，花一堆時間搬資料，然後再恢復原服務 (如 SQL、IIS等等)。至於比較麻煩的，像是目錄分享的，只好移掉再重建。中斷服務的時間就是從關機裝硬碟，一直到全部完成為止。
   
2. 用 disk clone 的工具，如 true image / ghost 之類的軟體。不過這樣通常得停機做 clone, 750GB 也是要執行好一段時間，加上我這次買的是 Advanced Format 的硬碟，用這類工具會有效能的問題，事後還得校正回來… ouch, 算了...

想來想去，我用的是 windows server, 有內建的 Mirror set, 就拿來用一用好了。我真正作的是把 mirror set 的兩顆都升級，不過為了簡化說明，我底下的例子就只以替換一般的硬碟就好，反正道理是一樣的。

說穿了不值錢，就是用 mirror 的磁碟複製特性，加上 extend volume 的功能，我除了需要關機裝上新硬碟之外，其它包含資料複製的所有時間，原服務都不用中斷 (當然速度會慢一點)，所有服務的設定也都不用修改，算是既無腦又防呆的完美方案... 只要簡單的按幾下滑鼠就可以達成我的目標。

直接來看看怎麼作的吧! 很簡單，先利用 mirror 把資料轉移到新硬碟... 然後中斷 mirror, 再用 extend volume 把磁區大小調大就可以收工了。來看分解步驟:

1. 我原本的磁碟組態是長這個樣子 (圖我是事後用 VM 模擬的)，其中 Disk 1 (8.00GB) 就是我要換掉的...
    
   
   
   
2. 關機裝上一顆新的硬碟 Disk 2 之後，變成這樣 (Disk 2 (16.00GB) 是新的硬碟):
   
   
   
   
3. 把 disk1 / disk2 做成磁碟鏡像之後，就變成這樣:
    
   
   
   
4. 鏡像做好，Resync 完成後，就可以中斷鏡像了。中斷之後變成這個樣子:
    
   
   
   
5. 目前為止，看來磁碟轉移已經完成了，剩下就是想辦法把後面的空間吃進來。接下來的就用 Extend Volume 括大 D: 的大小:
    
   

之後就大功告成了。這方法不但簡單，而且整個過程中，全程 D:\ 都可以正常的使用。除了 (1) --> (2) 需要關機裝硬碟之外， (2) ~ (5) 全程，放在 D:\ 的 SQL DB，IIS 網站，還有 pagefile 通通都正常運作中。有了 windows server 的磁碟陣列還真是好用啊 :D

不過，事情也是有黑暗面的... 這個方法是有幾個小缺點啦...

1. 被迫使用 "動態磁碟" :
   dynamic disk 其實不是什麼缺點啦，不過你要是會用到其它 OS，像 linux 之類的，或是用其它的磁碟管理軟體，可能就不認得了。這是缺點之一..
   
2. 只有 windows server 可以使用:
   desktop os (windows 2000 pro, xp, vista, win7) 都只支援部份的磁碟管理功能，這作法關鍵的 mirror 是不支援的... 只能乾瞪眼 @@
   
3. Extend Volume 只適用 windows 2008 以上的版本:
   記得 windows 2003 只支援到 span volume, 在 disk manager 裡還是會顯示兩個 partition, 只不過只會有一個磁碟機代號，容量會是兩個加起來的而已。一樣啦，是不會有什麼大問題，看起來不大爽而已 XD

偶爾換個口味，貼些小品文章，這邊我也不是很專業，有啥更好的作法也歡迎留 comment 啊 :D

上一篇廢話了這麼多，其實重點只有一個，我這次打算利用 CacheDependency 的機制，只要一聲令下，我想移除的 cache item 就會因為 CacheDependency 的關係自動失效，而不用很辛苦的拿著 cache key 一個一個移除。

我的想法是用 tags 的概念，建立起一套靠某個 tag 就能對應到一組 cache item，然後將它移除。開始之前先來想像一下 code 寫好長什麼樣子:

        static void Main(string[] args)
        {
            string[] urls = new string[] {
                "http://columns.chicken-house.net/",
                // 共 50 組網址... 略
            };

            foreach (string url in urls)
            {
                DownloadData(new Uri(url));
            }

            Console.ReadLine();
            TaggingCacheDependency.DependencyDispose("funp.com");
            Console.ReadLine();
        }

        private static void Info(string key, object value, CacheItemRemovedReason reason)
        {
                Console.WriteLine("Remove: {0}", key);
        }

        private static byte[] DownloadData(Uri sourceURL)
        {
            byte[] buffer = (byte[])HttpRuntime.Cache[sourceURL.ToString()];

            if (buffer == null)
            {
                // 直接到指定網址下載。略...
                buffer = null;

                HttpRuntime.Cache.Add(
                    sourceURL.ToString(),
                    buffer,
                    new TaggingCacheDependency(sourceURL.Host, sourceURL.Scheme),
                    Cache.NoAbsoluteExpiration,
                    TimeSpan.FromSeconds(600),
                    CacheItemPriority.NotRemovable,
                    Info);
            }

            return buffer;
        }
    }

   1:      static void Main(string[] args)

   2:      {

   3:          string[] urls = new string[] {

   4:              "http://columns.chicken-house.net/",

   5:              // 共 50 組網址... 略

   6:          };

   7:          foreach (string url in urls)

   8:          {

   9:              DownloadData(new Uri(url));

  10:          }

  11:          Console.ReadLine();

  12:          TaggingCacheDependency.DependencyDispose("funp.com");

  13:          Console.ReadLine();

  14:      }

  15:      private static void Info(string key, object value, CacheItemRemovedReason reason)

  16:      {

  17:              Console.WriteLine("Remove: {0}", key);

  18:      }

  19:      private static byte[] DownloadData(Uri sourceURL)

  20:      {

  21:          byte[] buffer = (byte[])HttpRuntime.Cache[sourceURL.ToString()];

  22:          if (buffer == null)

  23:          {

  24:              // 直接到指定網址下載。略...

  25:              buffer = null;

  26:              HttpRuntime.Cache.Add(

  27:                  sourceURL.ToString(),

  28:                  buffer,

  29:                  new TaggingCacheDependency(sourceURL.Host, sourceURL.Scheme),

  30:                  Cache.NoAbsoluteExpiration,

  31:                  TimeSpan.FromSeconds(600),

  32:                  CacheItemPriority.NotRemovable,

  33:                  Info);

  34:          }

  35:          return buffer;

  36:      }

  37:  }

這段 sample code 做的事很簡單，程式準備了 50 個網址清單，用 for-loop 一個一個下載。下載的 method: DownloadData(Uri sourceURL) 會先檢查 cache 是否已經有資料，沒有才真正下載 (不過下載的細節不是本篇要講的，所以就直接略過了...)。

而主程式的最後一行，則是想要把指定網站 ( funp.com ) 下載的所有資料，都從 cache 移除。為了方便觀看程式結果，我特地加上了 callback method, 當 cache item 被移除時, 會在畫面顯示資訊:

由執行結果來看，果然被移出 cache 的都是來在 funp.com 的網址... 接著來看看程式碼中出現的 TaggingCacheDependecny 是怎麼實作的。相關的 code 如下:

    public class TaggingCacheDependency : CacheDependency
    {
        private static Dictionary<string, List<TaggingCacheDependency>> _lists = new Dictionary<string, List<TaggingCacheDependency>>();

        public TaggingCacheDependency(params string[] tags)
        {
            foreach (string tag in tags)
            {
                if (_lists.ContainsKey(tag) == false)
                {
                    _lists.Add(tag, new List<TaggingCacheDependency>());
                }
                _lists[tag].Add(this);
            }
            this.SetUtcLastModified(DateTime.MinValue);
            this.FinishInit();
        }

        public static void DependencyDispose(string tag)
        {
            if (_lists.ContainsKey(tag) == true)
            {
                foreach (TaggingCacheDependency tcd in _lists[tag])
                {
                    tcd.NotifyDependencyChanged(null, EventArgs.Empty);
                }
                _lists[tag].Clear();
                _lists.Remove(tag);
            }
        }
    }

   1:  public class TaggingCacheDependency : CacheDependency

   2:  {

   3:      private static Dictionary<string, List<TaggingCacheDependency>> _lists = new Dictionary<string, List<TaggingCacheDependency>>();

   4:      public TaggingCacheDependency(params string[] tags)

   5:      {

   6:          foreach (string tag in tags)

   7:          {

   8:              if (_lists.ContainsKey(tag) == false)

   9:              {

  10:                  _lists.Add(tag, new List<TaggingCacheDependency>());

  11:              }

  12:              _lists[tag].Add(this);

  13:          }

  14:          this.SetUtcLastModified(DateTime.MinValue);

  15:          this.FinishInit();

  16:      }

  17:      public static void DependencyDispose(string tag)

  18:      {

  19:          if (_lists.ContainsKey(tag) == true)

  20:          {

  21:              foreach (TaggingCacheDependency tcd in _lists[tag])

  22:              {

  23:                  tcd.NotifyDependencyChanged(null, EventArgs.Empty);

  24:              }

  25:              _lists[tag].Clear();

  26:              _lists.Remove(tag);

  27:          }

  28:      }

  29:  }

30行不到... 其實程式很簡單，TaggingCacheDependency 繼承自 CacheDependency, 額外宣告一個靜態的 Dictionary<string, List<TaggingCacheDependency>> 來處理各個標簽及 TaggingCacheDependency 的關係，剩下的就沒什麼了。呼叫 DependencyDispose( ) 就可以通知 .NET Cache 機制，將相關的 cache item 移除。

用法很簡單，當你要把任何物件放進 cache 時，只要用 TaggingCacheDependency 物件來標示它的 tag:

                HttpRuntime.Cache.Add(
                    sourceURL.ToString(),
                    buffer,
                    new TaggingCacheDependency(sourceURL.Host, sourceURL.Scheme),
                    Cache.NoAbsoluteExpiration,
                    TimeSpan.FromSeconds(600),
                    CacheItemPriority.NotRemovable,
                    Info);

   1:  HttpRuntime.Cache.Add(

   2:      sourceURL.ToString(),

   3:      buffer,

   4:      new TaggingCacheDependency(sourceURL.Host, sourceURL.Scheme),

   5:      Cache.NoAbsoluteExpiration,

   6:      TimeSpan.FromSeconds(600),

   7:      CacheItemPriority.NotRemovable,

   8:      Info);

在這個例子裡 (line 4), 直接在 TaggingCacheDependency 物件的 constructor 上直接標上 tags, 在此例是直接把網址的 hostname, scheme 兩個部份當作 tag, 未來就可以依照這兩種資訊直接讓 cache 裡的相關物件失效。

而要下令讓 Cache 內有標上某個 tag 的 cache item 失效，只要這行:

            TaggingCacheDependency.DependencyDispose("funp.com");

   1:  TaggingCacheDependency.DependencyDispose("funp.com");

結果就會如同上面的程式範例一樣，還留在 cache 的該網址下載資料，在這一瞬間通通都會被清掉...

用這種方式，是不是比拿到 key 再去呼叫 Cache.Remove( key ) 的方式簡單多了呢? 同時也能夠更快速的處理複雜的移除機制。其實運用 tagging 的方式只是一例，需要的話你也可以設計合適的 CacheDependency 類別。

以下是本篇文章的兩個附加參考檔案:

每次心裡有什麼好點子想寫出來時，第一關就卡在想不出個好標題... 想來想去的標題，怎麼看就是既不顯眼又不聳動... 果然是個老實的工程師性格 =_= ...  這次要講的，是 .NET HttpRuntime 裡提供的 Cache 物件的操作心得。這個東西我想不用我多作介紹，大家都用到爛掉了吧? 不過好用歸好用，有個老問題其實一直困擾著我很久了...

" 我該怎麼手動的把某個物件從 cache 裡移除? "

老實說，這問題蠻沒水準的... 老叫別人要翻 MSDN，我自己怎麼沒翻? 不不... 容我花點篇幅先說明一下問題。Cache物件，是個典型的 Dictionary 型態的應用 (雖然它沒有 implement interface: IDictionary… ), 透過 key 就可以拿到 cached item. 要從 cache 裡移除某個 item, 簡單的很，只要用 Remove 這個 method, 一行就搞定了:

從 key 移除指定的 cache item[copy code]

HttpRuntime.Cache.Remove(“cache-key”);

   1:  HttpRuntime.Cache.Remove(“cache-key”);

別小看這一行，實作起來障礙還不少。首先，你得額外去記著 cache key 的值。當你要移除的 cache item 有多個的時後，或是移除的 items 之間的關係有點複雜時，這些 code 就不怎麼漂亮了。下一個問題是:

" 我該如何得知所有存在 Cache 內的 keys 有那些? "

這個問題單純的多，那些把 intelligent sense 當購物網站的人 (平常不看文件，只會按下 . 然後挑個順眼 method 來用的人)，可能這次就碰壁了... Cache 物件不像一般的 Dictionary 一樣，有提供 Keys 這樣的 property ... 它藏在 GetEnumerator 這 method 內，它會把所有的 keys 給巡一遍，你需要所有的 keys 的話，可以這樣用:

跑過 cache 裡每一個 key[copy code]

foreach (string key in HttpRuntime.Cache) { 
    // … 
}

   1:  foreach (string key in HttpRuntime.Cache) { 

   2:      // … 

   3:  }

不過這樣的風險也是蠻高的，誰曉得你拿到 key 後的下一秒，這個 cache item 還在不在 cache 內?

--------------------------------------------------------------

本文正式開始! 哈哈，前面那一段只是廢話 + 碎碎唸，現在才是正題。前面想表達的只是，因為 cache 的不確定性 (資料隨時都會被 remove), 操作起來變的要格外小心, 即使它用起來像一般的 Dictionary 一樣。

我舉個案例，來說明我應用 cache 的情況。假如我想實作一個簡單的 web browser, 透過網路下載資源是很慢的動作，每種 browser 都會有某種程度的 cache 機制。我們就拿 Cache 物件替代 IE 的 "temporary internet files” 目錄吧。這時很簡單，只要用 URL 當作 KEY，下載的 content 就當物件塞進去就好...

不過事情沒那麼簡單。如果程式運作了一陣子，我想提供使用者手動清除 "部份" cache 的功能的話，那該怎麼辦? 我舉幾種情況:

1. 從 cache 裡刪除所有從某個特定網站 (如: columns.chicken-house.net) 下載的資料
2. 從 cache 裡刪除所有特定類型的資料 (如: content-type 為 image/jpeg 的圖檔)
3. 從 cache 裡刪除所有透過特定 protocol (如: https) 下載的資料

這樣的要求應該不算過份吧? 用前面提到的兩種作法，你會想哭吧 XD .. 用這些基礎，你大概只能選這幾種作法 (各位網友有好作法也記得提供一下):

1. 自己另外管理所有下載過的 URL, 用盡各種適合的資料結構，讓你可以順利的挑出這些 match 的 key, 然後移除它。
   
   缺點: 都作這麼多，你乾脆自己重寫個 cache 機制好了... 何況時間一久，你管理的 key, 那些對應的資料搞不好老早就通通從 cache 裡清掉了...
   
2. 聰明一點，用 regular expression … 從 GetEnumerator( ) 一筆一筆過濾出要移除的 URL, 然後清掉它...
   
   缺點: 這作法只會檢查還留在 cache 內的 URL，不過這樣的 cache 隨便也有成千上萬個，每次都要 looping 掃一次實在不怎麼好看... 有違處女座有潔癖的個性...

這些方法 code 寫起來實在不怎麼漂亮，我就不寫 sample code 了，請各位自行想像一下寫起來的樣子。抱歉，如果你用的正好是上面的作法... 那請多包含... :D   這些都是 workable 的作法，但是看起來就是沒什麼設計感；程式可以動，不過就效能、簡潔、可讀性、美感來看，就是覺的不夠精緻 @@。跟朋友討論到這個問題時，我想到一個爛主意...

" 用蠢方法，這些 cache item 先分好類，每一類去關聯一個檔案，設 CacheDependency … 要清掉時去 touch 一下這個檔案，一整組的物件就會自動被清出 cache 了…。”

老實說，我覺的這是個既聰明又愚蠢的作法。聰明的是它很漂亮的解決我要如何移除某一群 item 的問題...，愚蠢的是這種單純程式內可以解決的事，竟然要繞到外面不必要的 file system I/O 動作... 而這通常是最慢的...

--

咳，寫太晚，實際的程式碼明天待續...

原定 #4 就提到的 "抽像化"，竟然被我連拖兩期，拖到 #6 才提到它... 人老了果然比較囉唆... 在前面的幾篇，重點都在如何 "具體" 的描述 "生命遊戲" 裡的細胞。不過現在要把這程式擴大到能容納各種不同的生物，先作好抽像化的工作是必要的...。

一般物件導向所指的 "抽像化"，是指你對某些事物的一般概念。比如有人問你:

"你會開車嗎?"

你腦袋裡想的應該是一般印像中的車子，有方向盤，排檔打下去，油門踩了就會前進，煞車踩了就會停下來...，這就是你對 "車子" 的抽像化。你不會去管車子是什麼牌的，什麼顏色，是二門跑車，或是休旅車之類的細節... 而你 "會" 開的車，也不會因為這些細節，有太大的不同。

這樣的抽像化概念，套用到考駕照這件事來說，你只要知道方向盤，油門等等的用法，同時也練習過，能正確的控制教練車，通過測驗，監理所就會發張駕照給你，證明你會開一般的車子。就算是在你學會開車後十年才上市發表的新車也是一樣。

看起來沒什麼了不起的描述，在電腦的世界裡可不是這麼一回事。Microsoft Word 1.0 想要順利開啟 Microsoft Word 6.0 的檔案，大概想都不用想，因為 1.0 版設計之初，有太多 6.0 版的變化是無法事先預料的，自然無法設計出能正確操作的程式，這現像在電腦的世界很正常。不過如果你兩年前考到的駕照，碰到兩年後的新車你就不會開了，甚至監理所還要求你重考張新的架照... 那這駕照等於一點用都沒有。中間的差別，就在於駕駛者對於開車的認知，跟實際的車子，中間是隔著一層 "抽像化" 的概念，而只要能掌握這抽像化的定義，就能順利操作未來的車種。

因此物件技術不斷的想要模擬這樣的關係，就發展出繼承這樣的方式，來表達這個概念。先用一個類別 (base class) 或是介面 (interface) 來表達這個 "抽像化" 的概念，而不表達細節。其它要跟它互動的程式，只能透過這個抽像化型別來溝通，而其它的細節或實作，則被藏在裡面，或是衍生類別。中間的故事我就不再多說了，再說我就直接去寫 OOP 的書好了 =_=，有興趣可以參考這本經典 [世紀末軟體革命]，有復刻版喔。套用到我們的 "生命遊戲" 裡，要定義的就是 "世界" 如何跟 "生命" 互動? 之間的關係是什麼? 另外就是 "生命" 有各種不同的型態，所有的 "生命" 型態是否都能順利的在同一個 "世界" 裡生存?

先試著用簡單文字來描述吧。在我們的定義裡，世界是個 M * N 的棋盤，每一格都能放一個生物。每個生物有自己的狀態 (生/死)，也會隨著時間與環境的不同，讓生物的狀態產生變化。畫成 UML 的 class diagram, 大概就像這樣 (手邊沒工具，用 power point 大概畫一下… Orz):

我們在撰寫程式時，就必需思考題目中講到的生物各種特性，那些是所有的生命共有的特色? 這部份要把它定義在 Life … 另一部份是某種細胞特有的，則要放在衍生類別 Cell 裡。而世界必需要能跟生命作適當的互動，讓生命的進行能繼續下去。這樣的架構好處是，未來如果有第二種 Cell 或是其它的生物，只要是從 Life 繼承下來，都能很順利的在 World 裡活著，因為物件導向技術的 "抽像化" 概念，保證這樣程式的可行性。

好，我們就以需要跟 World 接觸跟互動的部份為主，把原程式的 Cell 抽離出來，放到它的上層類別 Life 裡。這也是物件技術裡常提到的 "generalization" (一般化)，越一般的特性要越往上層類別移動，而越往下就是 "specialization" (特殊化)，底層的類別要去實作特殊的部份，或是特有的細節。

先把原程式作好調整吧。原 Cell 的程式碼，部份被搬移到 Life, 同時這兩個類別有了繼承關係，如下:

Life 的部份，定義了所有 Life 都該表達出來的特性，也就是我們對於 Life 的認知，都應該描述在裡面，像是 Life 活在 World (CurrentWorld) 裡，會有它的座標 (PosX, PosY), 也會有它在這個棋盤內顯示的方式 (DisplayText) 等。而跟 World 互動的方面，Life 則透過 GetNextWorldTask( ) 來讓 World 來讓 Life 驅動它生命的進行。

在 World 的這邊，不管是那種 Life 衍生類別的物件，一律都當成 Life 的 "抽像概念" 來操作。這樣的優點，在還不曉得未來這世界到底還有多少種不同的 Life 會在裡面生活時，主要程式就能開發了。未來 Life 可以一直擴充，衍生出多種不同的 Life 子類別，而 Life / World 之間的互動及規範，則可以完全不用修正。

接下來就要讓這遊戲的規則，變的更真實一點了。實際的情況下，應該是我們已經知道會有那些不同的生物，經過歸納 (一般化及特殊化) 之後，可以設計出我們需要的類別架構。不過實際寫起程式來可沒這麼好命 (就像 USER 永遠不會一次給你完整確定的需求一樣)，很多時後你得去 "猜" 或是 "假設"，因此跟本沒有 "一般化" 這回事，你得預先去猜測未來要應付什麼問題，而在細節都還不清楚時就先定義出上層類別。

我們開始來試看看，我們定義的夠不夠抽像吧! 如果助教看你這麼快就把生命遊戲的作業交出來，覺的很沒面子，想把題目變難一點，加上有病毒感染的情況。於是原題目的四條規則追加一條，變成這樣:

1. 孤單死亡：如果細胞的鄰居小於一個，則該細胞在下一次狀態將死亡。
2. 擁擠死亡：如果細胞的鄰居在四個以上，則該細胞在下一次狀態將死亡。
3. 穩定：如果細胞的鄰居為二個或三個，則下一次狀態為穩定存活。
4. 復活：如果某位置原無細胞存活，而該位置的鄰居為三個，則該位置將復活一細胞。
5. 感染：正常的細胞有 ( 1 + 受感染的鄰居數量 x5 )% 的機率受到病毒感染。已感染的細胞在 3 次狀態改變後會痊癒。受感染的狀況下，有 10% 的機率會死亡。

我們的程式該怎麼配合它改變? (對，機車的 USER 就都是這樣臨時修改規格...) 先來看看執行的結果，畫面上已經分的出來活著的 Cell 跟受感染的 Cell ... 除了看到 Cell 活著與死亡的變化之外，也看的到病毒擴散的狀況是怎麼樣。執行的畫面如下:

圖例: ◎受感染的細胞，●活著的正常細胞，○死亡的細胞

接著，來看看改版後的程式碼:

        public bool IsInfected        {            get { return this.InfectedCount > 0; }        }        private int InfectedCount = 0;        public override string DisplayText        {            get            {                if (this.IsAlive == true) return "●";                else if (this.IsInfected == true) return "◎";                else return "○";            }        }        protected override IEnumerable<TimeSpan> WholeLife()        {            yield return TimeSpan.FromMilliseconds(_rnd.Next(800, 1200));            for (int index = 0; index < int.MaxValue; index++)            {                int livesCount = 0;                int infectsCount = 0;                foreach (Cell item in this.FindNeighbors())                {                    if (item.IsAlive == true) livesCount++;                    if (item.IsInfected == true) infectsCount++;                }                bool? value = _table[this.IsAlive ? 1 : 0, livesCount];                if (value.HasValue == true)                {                    this.IsAlive = value.Value;                }                if (this.IsInfected == true)                {                    this.InfectedCount--;                    if (this.InProbability(10) == true) this.IsAlive = false;                }                else                {                    if (this.InProbability(1 + infectsCount * 5) == true) this.InfectedCount = 3;                }                yield return TimeSpan.FromMilliseconds(_rnd.Next(800, 1200));            }            this.Dispose();            yield break;        }

   1:  public bool IsInfected

   2:  {

   3:      get { return this.InfectedCount > 0; }

   4:  }

   5:  private int InfectedCount = 0;

   6:  public override string DisplayText

   7:  {

   8:      get

   9:      {

  10:          if (this.IsAlive == true) return "●";

  11:          else if (this.IsInfected == true) return "◎";

  12:          else return "○";

  13:      }

  14:  }

  15:  protected override IEnumerable<TimeSpan> WholeLife()

  16:  {

  17:      yield return TimeSpan.FromMilliseconds(_rnd.Next(800, 1200));

  18:      for (int index = 0; index < int.MaxValue; index++)

  19:      {

  20:          int livesCount = 0;

  21:          int infectsCount = 0;

  22:          foreach (Cell item in this.FindNeighbors())

  23:          {

  24:              if (item.IsAlive == true) livesCount++;

  25:              if (item.IsInfected == true) infectsCount++;

  26:          }

  27:          bool? value = _table[this.IsAlive ? 1 : 0, livesCount];

  28:          if (value.HasValue == true)

  29:          {

  30:              this.IsAlive = value.Value;

  31:          }

  32:          if (this.IsInfected == true)

  33:          {

  34:              this.InfectedCount--;

  35:              if (this.InProbability(10) == true) this.IsAlive = false;

  36:          }

  37:          else

  38:          {

  39:              if (this.InProbability(1 + infectsCount * 5) == true) this.InfectedCount = 3;

  40:          }

  41:          yield return TimeSpan.FromMilliseconds(_rnd.Next(800, 1200));

  42:      }

  43:      this.Dispose();

  44:      yield break;

  45:  }

細節我就不多介紹了。這裡的重點是經過抽像化的動作後，把 Life / Cell 之間的邏輯做明確的劃分。World 的類別程式碼完全沒有出現任何有關 Cell 的 Code, 只有出現 Life 而已。除了在主程式 GameHost 有這麼一段，明確的把 Cell 建立起來，把它放進 World:

        static void Main(string[] args)        {            int worldSizeX = 30;            int worldSizeY = 30;            World realworld = new World(worldSizeX, worldSizeY);            Random _rnd = new Random();            for (int x = 0; x < worldSizeX; x++)            {                for (int y = 0; y < worldSizeY; y++)                {                    Cell item = new Cell();                    realworld.PutOn(item, x, y);                }            }            // ...

   1:  static void Main(string[] args)

   2:  {

   3:      int worldSizeX = 30;

   4:      int worldSizeY = 30;

   5:      World realworld = new World(worldSizeX, worldSizeY);

   6:      Random _rnd = new Random();

   7:      for (int x = 0; x < worldSizeX; x++)

   8:      {

   9:          for (int y = 0; y < worldSizeY; y++)

  10:          {

  11:              Cell item = new Cell();

  12:              realworld.PutOn(item, x, y);

  13:          }

  14:      }

  15:      // ...

這樣的作法，其實已經引含了 "動態聯結" 的特性了。在開發主程式的階段 (指 World / Life 這兩個主要的 class), 都還沒有 Cell 的相關細節，而事後執行的程式碼卻可以依照 Cell 裡的邏輯來執行。這代表了我們不需要改主程式的設計，就能不斷的加入新的規責，甚至是新的生物進來一起運作。

如何? 物件技術的 "抽像化" 能力，的確很有效的解決了這樣的變化需求。下一篇會沿用一樣的架構，但是執行的範例會完全不一樣 (這次不用細胞了，直接用草原上的生態: 草、羊、虎) 的生命及規則，來套進這個框架，看看它能怎麼模擬出一個新的生態系統。

這樣的架構可以應付未來未知的變化，只要你的抽像化概念不變的前題下都沒問題。這種保留彈性，卻又不用在 design time 去多做不必要的實作，才是物件技術強大的地方。我舉個反例，很多剛入行的軟體工程師，你給他一個需求，他會想太多... 一個簡單的輸入 1 + 1 要顯示 2 的結果，他會這麼想:

USER 需不需要列印啊? 我先把這需求放進去好了，然後加個 config 預設關掉它，以免以後需要我還得大改程式...

只能算 1 + 1? 如果以後 USER 要算 3 * 5 怎麼辦? 好吧，我把 + 用一個 mode 來代表好了，以後 USER 需要括充為支援 +-*/ 就不用大改程式了...

...

碰到這些狀況，我只能誇獎這位年青有為的程式設計師一句話:

"你很認真... 辛苦了..."

不過我心裡會苦笑... 只不過要你寫個 1 + 1 = 2，搞這麼一大包? 多作考慮，預留未來可能需要的功能，不是件壞事。不過既然是未知的需求，你又如何保證你能夠正確的 "預知" ，然後進一步 "預留" ? 何況這些多做的需求，未來真正會用上的有多少? 用不到的話，只是開發成本的浪費，及讓你的架構複雜性提高，維護的困難增加而已。物件技術真的解決的了這種問題嗎? 下一篇的目標，我們會定在不修改 World / Life 的設計為前題，把生命遊戲的模擬內容換成草原的生態模擬。敬請期待續集 :D

最近這兩個禮拜，很扯... 我的手機時鐘越來越不準，竟然每天會晚個幾分鐘，不到兩個禮拜，竟然跟正常時間比起來已經差了廿分鐘...

天那，這什麼時代了，一個五十塊的電子錶都比我這隻五為數價位 (幾年前的價位啦 =_=) 的手機準時... 怪的是，白天再公司又是準的 !? 越看越怪，難不成這時代，連看個時鐘都得先 DEBUG 一番... 今天就花了點心思追一下問題 @@

首先，原來慢的不是我的手機，而是我家裡的 PC，因為手機插上 USB 充電 + SYNC，會順便對時，就這樣誤差越來越大了。不過 PC 不是都會上網對時嘛? 後來就再繼續追下去...

繼續追下去，家裡 PC 是跟家裡的 SERVER (domain controller) 對時的... 原來時間慢的是家裡的 SERVER... 不過問題還是一樣啊! 現在一直都連上網的 SERVER 怎麼可能會這樣?

因為每次重灌，一堆帳號就要重建，很麻煩，所以上個月重灌 SERVER時，就順手在 VM 裡裝了台 SERVER，當作 Active Directory 的 domain controller (Guest OS)… 而 SERVER 本身 (Host OS) 才是拿來做 NAT / RRAS / FILE SERVER 等服務...

這樣的架構，機車的地方就在於: Hyper-V 本身 VM 會跟 Host 做 time sync ... 而 Host 有加入 AD, Host 又會跟 Guest 同步時間，Hyper 又替 Guest 跟 Host 同步時間... 每次誤差一點，幾週下來就變這樣了 @@ 害我的手機莫名奇妙就晚了快半小時...

果然，這選項移除後，就一切正常了 @@，頂多就讓 DC 脫褲子放屁，到外面的 server 去對時吧... 嗯，這年頭，真的什麼怪事都會發生... 還好這次有抓到問題，哈哈... 這篇就給跟我一樣宅的人參考吧 :D

在繼續下去之前，先來講一下，我希望讓這個 "生命遊戲" 程式，發展到什麼程度吧。其實前面四篇都還只是基礎入門，跟準備動作而已，接下來才開始會有些有趣的。

我希望這系列文章寫完後，這個程式要能扮演一個真正可運作的 Matrix … 沒錯，就是像電影駭客任務裡的母體一樣，這個程式會變成 Matrix 的主要架構，而各式各樣的 "生物" 可以在這個虛擬世界裡生活。為了讓它真的跑的動，所以前幾篇提到的效能問題，執行緒問題，就不能不考慮。為了讓這個虛擬世界能更擬真一點，它至少要是個依時間驅動的模式，而不是像 "生命遊戲" 最早定義的回合制，因此這個問題也要在基本架構裡解決掉。

這些 "生物" 那裡來? 當然是大家來開發 :D 最終目標是要把這 Matrix 建起來，讓各位的生物可以放進來互相較勁一番... 因此先替這些程式 (生物) 抽像化，定義好它跟世界，及跟其它生物之間互動的規格 (就是下篇 "抽像化 / 多型" 要說的) 就是必要的工作之一了。替生命定義好抽像化介面之後，就可以開始衍生出各種不同的生命型態，一起加入這個虛擬世界，因此繼承、多型的技術就派上用場了。

生命是會演化的，當世界上真的演化出一種新的生命型態時，整個世界可以 "安裝" 好新的生命型態，然後全部存檔，重新啟動嗎? 當然不行... 因此如何 "動態" 的加入新的生命型態，如何不停止 GameHost 的前提下，由新的 Assembly 載入 Class (再下篇要說明的 "動態載入")，也是必需克服的技術之一。

這幾個階段及目標，就是我這一系列文章想要做到的。聽起來好像很有趣，可是卻又沒什麼實際的用途... Orz, 沒辦法，我就是喜歡寫這類要動點腦筋的程式，即使畫面一點都不炫也沒關係... 平常工作就不大有機會寫這種程式了，加上現在又只剩一張嘴...。

如果順利的發展，我倒是有個打算，這個 GameHost 成形之後，我打算定些基本的規則，比如土地上會有一定的機率及規則，長出草 (食物) 來。而這世界有各種不同的生物 (EX: 羊)，需要靠這世界上的資源維持生命。到時大家可以把自己創造的 "羊" 一起放到這個世界內，看看執行了一陣子之後，誰設計的 "品種" 比較好，最後可以一代一代的繁衍下來...。

想的很美好，不過我不像 darkthread 可以替最後優勝的造物者提供獎品.. Orz.. 未來的設計藍圖就先規劃到這裡。在繼續下去之前，我把程式重新整理了一下，有興趣的人可以下載回去。這份程式碼跟 #4 的功能結構是一樣的，只不過整個架構都作過重整，變數等命名也調整過了，是為了往後說明相關物件技術時，不會被這些從 #1 ~ #4 改的支離破碎的程式碼干擾...

嗯，講了一堆廢話，結論就是: 敬請期待續集 :D  哈哈...

下載重整過的程式碼:

原本這篇不講執行緒，要直接跳到 OOP 多型的應用... 不過看一看 #3 自己寫的程式，實在有點看不下去... 30x30 的大小，程式跑起來就看到 903 條執行緒在那邊跑... 而看一下 CPU usage, 只有 5% 不到... 這實在不是很好看的實作範例，如果這是線上遊戲的 SERVER 程式，裡面的每個人，每個怪物等等都用一條專用的執行緒在控制他的行為的話，我看這遊戲不用太多人玩，SERVER 就掛掉了吧! 因此要繼續更貼近實際的生命模擬遊戲前，我們先來解決效能的問題，所以多安插了這篇進來 :D

前一篇 (#3) 的主題是把生命的進行，從被動的在固定時間被喚醒 (callback) 的作法，改成主動的在指定時間執行 (execute)。 想也知道，現實世界的生物都是 "主動" 的，後面的作法比較符合 OOP 的 "模擬世界，加以處理" 的精神。但是，一個小程式就吃掉 900 條執行緒，是有點過頭了。不知道還有沒有人記得，我騙到獎品的這個程式... 很另類的用 yield return 來解決類似問題的作法... 藉著 compiler 很雞婆的把單一流程翻成數段可以切開執行的邏輯...，正好拿來利用一下，替我們把一連串連續的邏輯切段，以便利用多執行緒來處理。我的想法是這樣，原程式是用個迴圈，作完該作的事，就休息 (sleep) 一段時間。而新的寫法，我打算用 yield return new TimeSpan(…) 來取代 Thread.Sleep(…)。每個 Cell內部的程式結構修改不大，不過對於 GameHost 就是個挑戰了... 來看看修改前及修改後的程式碼:

        // 修改前
        // 使用 Thread.Sleep( ) 來控制時間
        public void WholeLife(object state)
        {
            int generation = (int)state;
            for (int index = 0; index < generation; index++)
            {
                this.OnNextStateChange();
                Thread.Sleep(_rnd.Next(950, 1050));
            }
        }
        //
        //
        //
        // 修改後
        // 使用 yield return new TimeSpan( ) 來控制時間
        public IEnumerable<TimeSpan> WholeLife(object state)
        {
            int generation = (int)state;
            for (int index = 0; index < generation; index++)
            {
                this.OnNextStateChange();
                yield return TimeSpan.FromMilliseconds(_rnd.Next(950, 1050));
            }
            yield break;
        }

   1:  // 修改前

   2:  // 使用 Thread.Sleep( ) 來控制時間

   3:  public void WholeLife(object state)

   4:  {

   5:      int generation = (int)state;

   6:      for (int index = 0; index < generation; index++)

   7:      {

   8:          this.OnNextStateChange();

   9:          Thread.Sleep(_rnd.Next(950, 1050));

  10:      }

  11:  }

  12:  //

  13:  //

  14:  //

  15:  // 修改後

  16:  // 使用 yield return new TimeSpan( ) 來控制時間

  17:  public IEnumerable<TimeSpan> WholeLife(object state)

  18:  {

  19:      int generation = (int)state;

  20:      for (int index = 0; index < generation; index++)

  21:      {

  22:          this.OnNextStateChange();

  23:          yield return TimeSpan.FromMilliseconds(_rnd.Next(950, 1050));

  24:      }

  25:      yield break;

  26:  }

別想的太美，只改這樣，程式是不會動的... 修改過之後，麻煩的地方會在 GameHost. 因為整個 GameHost 的邏輯都反過來了。原本是 GameHost 只要放著那九百條執行緒自生自滅，它只要不斷的刷新畫面就好了。現在它則得用 foreach(…) 去詢問:

"大爺，這次您要休息多久?"

接到 yield return 傳回的 TimeSpan 物件 (代表它要休息多久後，繼續下一個動作) 後，經過這段時間，GameHost 就要再去叫醒 cell, 然後再詢問一次:

"大爺，這次您要休息多久?"

關鍵就在於 GameHost 如何能透過少量的 thread 來伺後這些大爺，而不是像 #3 的程式一樣，每個大爺都用一條專屬的 thread… 要共用執行緒，就要先想辦法把工作切碎，這是基本法則。如果你希望你的生命遊戲程式不只是作業的話，那麼效能跟即時回應的問題是必需要考慮的。在動手改寫 GameHost 程式之前，先來分析一下改寫的目標有那些:

目標是要達到像 #2 範例一樣的效果，但是要用更有效率的方式。

目標很清楚，再來就看看有什麼手段可以用了。第一個是過量的執行緒，應該要想辦法改用執行緒集區。因為 #2 用了高達 900 條執行緒，不過整體 CPU USAGE 不到 5%，大部份的執行緒都在閒置狀態。如果能想辦法把這些運算丟到執行緒集區，由集區動態管理會有效率的多。

第二，就是把原本的 Thread.Sleep(ts) 改成 yield return ts 後，原本每個 thread 自己睡覺的機制，就要改成 cell 各自回報 game host 它想要睡多久，然後由 game host 統一在時間到時叫醒它。由於一次有多個 cell 同時在運作，因此我們需要一個簡單的排程器，作法像這樣:

1. 建立一個時間表，依照時間順序，把每個 cell 預計要被叫醒的時間標上去。
2. 時間到了之後，就去呼叫該 cell 的 OnNextStateChangeEx()，同時取得該 cell 下次要喚醒的時間，再標到時間表上
3. GameHost就不斷的替每個 cell 重複 (1) (2) 的動作..
4. 同時另外用一條獨立的執行緒，作畫面更新的動作。

嗯，要處理的方式越來越清楚了。剩下的是 "時間表" 要用什麼型式來表現? 我的選擇是，我希望它是個 ToDo List, 會幫我排好時間，我只要把工作標上時間，丟進 ToDo List, 然後 ToDo List 只要能忠實的回報給我還有沒有排定的工作? 如果有，下一個要處理的工作是那一個? 什麼時後處理?

它的用法只有丟工作進去，跟拿工作出來，因此我設計它的公開介面長這個樣子:

        public class CellToDoList
        {
            public void AddCell(Cell cell) {...}
            public Cell GetNextCell() {...}
            public Cell CheckNextCell() {...}
            public int Count {get;}
        }

   1:  public class CellToDoList

   2:  {

   3:      public void AddCell(Cell cell) {...}

   4:      public Cell GetNextCell() {...}

   5:      public Cell CheckNextCell() {...}

   6:      public int Count {get;}

   7:  }

裡面的實作，我就不多說了。我是把它當成 QUEUE 在設計，唯一的差別是，放進 QUEUE 的東西會先經過排序，因此不見得是 "First In First Out" 這種典型的貯列，而是會以 Cell 上標示的時間為準，依序 Out …。實作起來很簡單，用現成的 SortedList 當內部的儲存方式，加上基本的 lock 機制來確保它是 thread safe 的就夠了。

好，這些雞絲都準備好之後，就可以來打造我們的新版 GameHost 了。來看看 Code:

        static CellToDoList _cq;
        static void _YieldReturnGameHost(string[] args)
        {
            int worldSizeX = 30;
            int worldSizeY = 30;

            World realworld = new World(worldSizeX, worldSizeY);

            _cq = new CellToDoList();
            // init threads for each cell
            for (int positionX = 0; positionX < worldSizeX; positionX++)
            {
                for (int positionY = 0; positionY < worldSizeY; positionY++)
                {
                    Cell cell = realworld.GetCell(positionX, positionY);
                    cell.OnNextStateChangeEx();
                    _cq.AddCell(cell);
                }
            }

            // 啟動定期更新畫面的執行緒
            Thread t = new Thread(RefreshScreen);
            t.Start(realworld);

            while (_cq.Count > 0)
            {
                Cell item = _cq.GetNextCell();
                if (item.NextWakeUpTime > DateTime.Now)
                {
                    // 時間還沒到，發呆一下等到時間到為止
                    Thread.Sleep(item.NextWakeUpTime - DateTime.Now);
                }
                
                ThreadPool.QueueUserWorkItem(RunCellNextStateChange, item);
            }
        }

        private static void RunCellNextStateChange(object state)
        {
            Cell item = state as Cell;
            TimeSpan? ts = item.OnNextStateChangeEx();
            if (ts != null) _cq.AddCell(item);
        }


        private static void RefreshScreen(object state)
        {
            while (true)
            {
                Thread.Sleep(500);
                (state as World).ShowMaps("");
            }
        }

   1:  static CellToDoList _cq;

   2:  static void _YieldReturnGameHost(string[] args)

   3:  {

   4:      int worldSizeX = 30;

   5:      int worldSizeY = 30;

   6:      World realworld = new World(worldSizeX, worldSizeY);

   7:      _cq = new CellToDoList();

   8:      // init threads for each cell

   9:      for (int positionX = 0; positionX < worldSizeX; positionX++)

  10:      {

  11:          for (int positionY = 0; positionY < worldSizeY; positionY++)

  12:          {

  13:              Cell cell = realworld.GetCell(positionX, positionY);

  14:              cell.OnNextStateChangeEx();

  15:              _cq.AddCell(cell);

  16:          }

  17:      }

  18:      // 啟動定期更新畫面的執行緒

  19:      Thread t = new Thread(RefreshScreen);

  20:      t.Start(realworld);

  21:      while (_cq.Count > 0)

  22:      {

  23:          Cell item = _cq.GetNextCell();

  24:          if (item.NextWakeUpTime > DateTime.Now)

  25:          {

  26:              // 時間還沒到，發呆一下等到時間到為止

  27:              Thread.Sleep(item.NextWakeUpTime - DateTime.Now);

  28:          }

  29:          ThreadPool.QueueUserWorkItem(RunCellNextStateChange, item);

  30:      }

  31:  }

  32:  private static void RunCellNextStateChange(object state)

  33:  {

  34:      Cell item = state as Cell;

  35:      TimeSpan? ts = item.OnNextStateChangeEx();

  36:      if (ts != null) _cq.AddCell(item);

  37:  }

  38:  private static void RefreshScreen(object state)

  39:  {

  40:      while (true)

  41:      {

  42:          Thread.Sleep(500);

  43:          (state as World).ShowMaps("");

  44:      }

  45:  }

GameHost 的工作很明確，一開始 (line 18 ~ 20) 就把更新畫面的動作完全交給另一個執行緒，之後就專心處理 ToDoList 內的工作了。

接著後面的 while loop (line 21 ~ 30) 則是很單純的從 ToDoList 裡取出下一個要要動作的 Cell, 如果時間還沒到就 Sleep 等一下它。執行完後會再詢問下一次是什麼時後，同時再把他加到 ToDoList 內等待下一次輪到他時繼續。

這次的程式我沒有設定停止的條件，因此你會看到程式會不斷的執行下去。程式執行起來，結果跟 #3 沒什麼不同，畫面上的每個細胞會照著題目的規則生長或死亡，不同的是 #3 的 Game Host 需要用到 903 條執行緒，而這版的 Game Host 只要 9 條執行緒...

其實，以這樣的範例題，我大可以不用顧慮到效能的問題，不過就是示範程式怎麼寫嘛。不過，我的目標如果只是訂在怎麼寫這練習題，大可以 GOOGLE 一下就有一堆作業解答了 :D。我的目標是要展示一下，該如何開發這樣的 GameHost ? 這樣的程式，是大部份的遊戲的基礎，尤其是像線上遊戲或是 facebook 這類互動遊戲的基礎。有了像樣的 Game Host 之後，接下來就把目標放在如何建立多樣的生物，一起放在這世界裡面生活了。接下來就會大量運用到 OOP 的特點 (對，就是上一篇預告的...) 繼承及多型。

有沒有人覺的，這種程式越寫越像 Matrix (就是駭客任務裡的 "母體") 了? 裡面活著的東西其實都在我的掌控之下... =_= 哈哈... 未完待續，請期待續集 :D。

--
範例程式:

原本的範例，其實有些盲點，不知各位有沒看到? 一樣的起始狀態，一樣的遊戲規則，你不一定會得到一樣的結果。為什麼? 因為這會跟你程式 SCAN 的順序有關。怎麼說? 因為到目前為只，整個遊戲就好像下棋一樣，是 "回合制"，我下完了換你... 一路一直輪下去。

這時先下後下就會影響結果了。現實世界的生命不是這樣的啊... 不知有沒有人玩過早期的太空戰士 (Final Fantasy) 系列遊戲? 當年 FF 有個很重要的突破，就是把 RPG 從傳統的 "回合制" 改成即時戰鬥... 每個人都有個倒數的碼錶，數到 0 你就可以發動下一次的攻擊... 這樣才接近現實世界啊。套用到我們的生命遊戲，這次我們想作的改變，就是把程式改成這種模式。

因此來調整一下規則，每個細胞每隔 1000ms 後會進到下一個狀態。不過生命總是沒有完全一樣的，因此每個細胞進到下一個狀態的時間差，都會有 10% 的誤差 (也就是 950ms ~ 1050ms 之間的時間都有可能)。其它規責則維持不變，來看看程式該怎麼改寫。

這種 "即時制"，是比較合乎現實的情況的，如果未來你想發展到像 facebook 上的那些小遊戲，或是其它線上遊戲一樣的話， "回合制" 是決對行不通的... 這時，我們可以想像，每個細胞都有自己的執行緒，每換過一次狀態後就 Sleep() 一段時間，醒來再換到下一次狀態... 一直到指定的世代 (generation) 到達為止。

來看一下改版過的程式。我們先不動原本的 Cell, 只追加一個 method: WholeLife( ), 呼叫後就會一直更新這個細胞的狀態，直到它結束為止 (不是死掉喔，是 generation 到達)。而整個世界的所有細胞，都是獨立的個體，都有個專屬的執行緒在運作...。這時 Game Host 就得換個方式來讓這些細胞過日子 (執行)，同時 Game Host 好像有個人造衛星一樣，不斷的在上空拍照來更新畫面，而完全不影響這些細胞的生命進行。

來看一下改寫過的 Cell 追加的 method:

        public void WholeLife(object state)
        {
            int generation = (int)state;
            for (int index = 0; index < generation; index++)
            {
                this.OnNextStateChange();
                Thread.Sleep(_rnd.Next(950, 1050));
            }
        }

   1:  public void WholeLife(object state)

   2:  {

   3:      int generation = (int)state;

   4:      for (int index = 0; index < generation; index++)

   5:      {

   6:          this.OnNextStateChange();

   7:          Thread.Sleep(_rnd.Next(950, 1050));

   8:      }

   9:  }

改變不大，只是多個簡單的迴圈，跟 sleep 來控制時間而已。再來看看 Game Host 要怎麼改:

        static void Main(string[] args)
        {
            int worldSizeX = 30;
            int worldSizeY = 30;
            int maxGenerationCount = 100;

            World realworld = new World(worldSizeX, worldSizeY);

            // init threads for each cell
            List<Thread> threads = new List<Thread>();
            for (int positionX = 0; positionX < worldSizeX; positionX++)
            {
                for (int positionY = 0; positionY < worldSizeY; positionY++)
                {
                    Cell cell = realworld.GetCell(positionX, positionY);
                    Thread t = new Thread(cell.WholeLife);
                    threads.Add(t);
                    t.Start(maxGenerationCount);
                }
            }

            // reflesh maps
            do
            {
                realworld.ShowMaps("");
                Thread.Sleep(100);
            } while (IsAllThreadStopped(threads) == false);

            // wait all thread exit.
            foreach (Thread t in threads) t.Join();
        }

        private static bool IsAllThreadStopped(List<Thread> threads)
        {
            foreach (Thread t in threads)
            {
                if (t.ThreadState != ThreadState.Stopped) return false;
            }
            return true;
        }

   1:  static void Main(string[] args)

   2:  {

   3:      int worldSizeX = 30;

   4:      int worldSizeY = 30;

   5:      int maxGenerationCount = 100;

   6:      World realworld = new World(worldSizeX, worldSizeY);

   7:      // init threads for each cell

   8:      List<Thread> threads = new List<Thread>();

   9:      for (int positionX = 0; positionX < worldSizeX; positionX++)

  10:      {

  11:          for (int positionY = 0; positionY < worldSizeY; positionY++)

  12:          {

  13:              Cell cell = realworld.GetCell(positionX, positionY);

  14:              Thread t = new Thread(cell.WholeLife);

  15:              threads.Add(t);

  16:              t.Start(maxGenerationCount);

  17:          }

  18:      }

  19:      // reflesh maps

  20:      do

  21:      {

  22:          realworld.ShowMaps("");

  23:          Thread.Sleep(100);

  24:      } while (IsAllThreadStopped(threads) == false);

  25:      // wait all thread exit.

  26:      foreach (Thread t in threads) t.Join();

  27:  }

  28:  private static bool IsAllThreadStopped(List<Thread> threads)

  29:  {

  30:      foreach (Thread t in threads)

  31:      {

  32:          if (t.ThreadState != ThreadState.Stopped) return false;

  33:      }

  34:      return true;

  35:  }

其實這卅幾行 code, 大都花在控制執行緒上面，有興趣的讀者可以翻翻我之前寫的那系列文章，我就不多作說明了。調整之後，這個世界變的更不可測了，一樣的起始環境，連上帝 (在這模擬世界裡，我就是上帝 XD) 都無法預測下一秒會發生什麼事...

感覺就好像看電視一樣。畫面不斷的在閃動，而畫面裡的細胞會不規責的跳動，不像上一版程式一樣，每刷一次就變一次那樣的枯燥無聊。如果畫面呈現的地方再多用點心思，就可以弄的像卡通一樣，每個細胞都各自用自己的步調在活著...

到這裡，如何? 應該沒有人把作業寫到這個樣子了吧 XD (就說別抄我的程式去交作業了)。不適當的利用執行緒，也做的到類似的結果。不過，你花費的代價會很大，因為你的程式得自己來做 context switch (這些是 OS + thread scheduler 會幫你解決掉的，只要你曉得要用 thread)。

接下來下一篇，我們再繼續調整這世界的遊戲規則，加入更多元素進去，看看程式會變怎樣? 多執行緒解決時間的問題了，再來我們要用繼承及多型，讓不同的生命可以在同一個世界下共同生活...  ((待續))

還好，第一版的程式沒有難產。這版的目的很簡單，就是把題目實作出來，同時我會盡量套用物件導向的理念去設計程式的結構，而不是只把結果算出來而已。其實我一直覺的，這類生命模擬的程式，是非常適合用OOPL來實作的範例，大概OOPL所有強調的特性 (封裝、繼承、多型、動態聯結... 等等) 都用的到，算是完美的應用範例題吧!

不過很奇怪的，我特地 GOOGLE 了一下，不知 OOPL 高手都不屑寫這種範例還是怎樣，找到的範例程式，不管用什麼語言 (C/C++/Java/C#都有) 寫的，清一色都很沒有物件導向的 fu ... 好吧，只好自己來寫一個。

第一步，一定是先看看你的程式，分析出需要那些類別/物件，及它們之間的關係。比較正規的作法就是 UML 的 UseCase 了。不過這範例其實不大，我就直接跳到 Class Diagram 了 (因為VS2008剛好有現成的...)... 主要的類別有兩個: World (世界) 及 Cell (細胞)。

World 就是給 Cell 生活的空間，我們只訂義一個有限大小的二維空間，就一個 M x N 的棋盤這樣。而 Cell 則是一個細胞，描述單一一個細胞本身，在各種不同的條件下會有什麼反應。先貼一下 class diagram:

  
圖1. class diagram (World & Cell)

老實說，這張圖還蠻乏善可陳的，World對外公開的介面，大概包含了幾個主要功能，就是取得指定座標的 Cell (GetCell), 及把目前的整個 World 狀態印出來 (ShowMaps) 的 method 而已。而 Cell 的公開介面，不外乎是它目前是活著還是死的，還有它的建構式，及呼叫後會把狀態轉移到下一次狀態的 method。

其它都是 World / Cell 互相溝通用，或是 Init 用的 Method / Prop, 就不多作介紹。先來看看主程式，扮演上帝的你，如何讓這堆單細胞生物，在你的世界裡活起來:

        static void Main(string[] args)
        {
            int worldSizeX = 30;
            int worldSizeY = 30;
            int maxGenerationCount = 100;

            World realworld = new World(worldSizeX, worldSizeY);
            for (int generation = 1; generation <= maxGenerationCount; generation++)
            {
                realworld.ShowMaps(string.Format("Generation: {0}", generation));
                Thread.Sleep(1000);

                for (int positionX = 0; positionX < worldSizeX; positionX++)
                {
                    for (int positionY = 0; positionY < worldSizeY; positionY++)
                    {
                        // do day pass
                        Cell cell = realworld.GetCell(positionX, positionY) as Cell;
                        cell.OnNextStateChange();
                    }
                }
            }
        }

   1:  static void Main(string[] args)

   2:  {

   3:      int worldSizeX = 30;

   4:      int worldSizeY = 30;

   5:      int maxGenerationCount = 100;

   6:      World realworld = new World(worldSizeX, worldSizeY);

   7:      for (int generation = 1; generation <= maxGenerationCount; generation++)

   8:      {

   9:          realworld.ShowMaps(string.Format("Generation: {0}", generation));

  10:          Thread.Sleep(1000);

  11:          for (int positionX = 0; positionX < worldSizeX; positionX++)

  12:          {

  13:              for (int positionY = 0; positionY < worldSizeY; positionY++)

  14:              {

  15:                  // do day pass

  16:                  Cell cell = realworld.GetCell(positionX, positionY) as Cell;

  17:                  cell.OnNextStateChange();

  18:              }

  19:          }

  20:      }

  21:  }

主程式我還沒把不相干的動作刪掉，也才廿一行... line 1 ~ 5 只是初始值，line 6 建立整個世界，之後就每跑完一個世代 (generation) 就休息一秒鍾，繼續下一次進化。這樣隨著時間的過去，畫面上會一直更新整個世界的狀態... 直到只定的次數到了為止。

class World 的部份就沒什麼特別的，就只是把一個二維陣列包裝一下而已。直接貼 Code 就混過去吧 XD，一樣沒有刪掉程式碼，原 CODE 照貼:

    public class World
    {
        private int SizeX = 0;
        private int SizeY = 0;
        private Cell[,] _map;
        public World(int maxPosX, int maxPosY)
        {
            this._map = new Cell[maxPosX, maxPosY];
            this.SizeX = maxPosX;
            this.SizeY = maxPosY;

            for (int posX = 0; posX < maxPosX; posX++)
            {
                for (int posY = 0; posY < maxPosY; posY++)
                {
                    this._map[posX, posY] = new Cell(this, posX, posY);
                }
            }
        }

        internal void PutOn(Cell item, int posX, int posY)
        {
            if (this._map[posX, posY] == null)
            {
                this._map[posX, posY] = item;
                item.PosX = posX;
                item.PosY = posY;
            }
            else
            {
                throw new ArgumentException();
            }
        }

        public Cell GetCell(int posX, int posY)
        {
            if (posX >= this.SizeX) return null;
            if (posY >= this.SizeY) return null;
            if (posX < 0) return null;
            if (posY < 0) return null;

            return this._map[posX, posY];
        }

        public void ShowMaps(string title)
        {
            Console.Title = title;
            Console.SetWindowSize(this.SizeX * 2, this.SizeY);
            Console.SetCursorPosition(0, 0);
            Console.Clear();

            for (int y = 0; y < this.SizeY; y++)
            {
                for (int x = 0; x < this.SizeX; x++)
                {
                    Cell item = this.GetCell(x, y);
                    Console.SetCursorPosition(x * 2, y);
                    Console.Write(item.IsAlive? "●":"○");
                }
            }
        }
    }

   1:  public class World

   2:  {

   3:      private int SizeX = 0;

   4:      private int SizeY = 0;

   5:      private Cell[,] _map;

   6:      public World(int maxPosX, int maxPosY)

   7:      {

   8:          this._map = new Cell[maxPosX, maxPosY];

   9:          this.SizeX = maxPosX;

  10:          this.SizeY = maxPosY;

  11:          for (int posX = 0; posX < maxPosX; posX++)

  12:          {

  13:              for (int posY = 0; posY < maxPosY; posY++)

  14:              {

  15:                  this._map[posX, posY] = new Cell(this, posX, posY);

  16:              }

  17:          }

  18:      }

  19:      internal void PutOn(Cell item, int posX, int posY)

  20:      {

  21:          if (this._map[posX, posY] == null)

  22:          {

  23:              this._map[posX, posY] = item;

  24:              item.PosX = posX;

  25:              item.PosY = posY;

  26:          }

  27:          else

  28:          {

  29:              throw new ArgumentException();

  30:          }

  31:      }

  32:      public Cell GetCell(int posX, int posY)

  33:      {

  34:          if (posX >= this.SizeX) return null;

  35:          if (posY >= this.SizeY) return null;

  36:          if (posX < 0) return null;

  37:          if (posY < 0) return null;

  38:          return this._map[posX, posY];

  39:      }

  40:      public void ShowMaps(string title)

  41:      {

  42:          Console.Title = title;

  43:          Console.SetWindowSize(this.SizeX * 2, this.SizeY);

  44:          Console.SetCursorPosition(0, 0);

  45:          Console.Clear();

  46:          for (int y = 0; y < this.SizeY; y++)

  47:          {

  48:              for (int x = 0; x < this.SizeX; x++)

  49:              {

  50:                  Cell item = this.GetCell(x, y);

  51:                  Console.SetCursorPosition(x * 2, y);

  52:                  Console.Write(item.IsAlive? "●":"○");

  53:              }

  54:          }

  55:      }

  56:  }

接下來是封裝每個細胞本身跟環境互動的影響，把上一篇講的規則對應成程式碼的樣子。先來看看 CODE:

    public class Cell //: Life
    {
        protected World CurrentWorld { get; private set; }

        internal int PosX = 0;
        internal int PosY = 0;

        private const double InitAliveProbability = 0.2D;


        private static Random _rnd = new Random();
        public Cell(World world, int posX, int posY) //: base(world, posX, posY)
        {
            this.CurrentWorld = world;

            // setup world
            this.PosX = posY;
            this.PosY = posY;
            this.CurrentWorld.PutOn(this, posX, posY);

            this.IsAlive = (_rnd.NextDouble() < InitAliveProbability);
        }

        public bool IsAlive { get; private set; }

        protected IEnumerable<Cell> FindNeighbors()
        {
            foreach (Cell item in new Cell[] {
                this.CurrentWorld.GetCell(this.PosX -1, this.PosY-1),
                this.CurrentWorld.GetCell(this.PosX, this.PosY-1),
                this.CurrentWorld.GetCell(this.PosX+1, this.PosY-1),
                this.CurrentWorld.GetCell(this.PosX-1, this.PosY),
                this.CurrentWorld.GetCell(this.PosX+1, this.PosY),
                this.CurrentWorld.GetCell(this.PosX-1, this.PosY+1),
                this.CurrentWorld.GetCell(this.PosX, this.PosY+1),
                this.CurrentWorld.GetCell(this.PosX+1, this.PosY+1)})
            {
                if (item != null) yield return item;
            }
            yield break;
        }

        public void OnNextStateChange()
        {
            int livesCount = 0;
            foreach (Cell item in this.FindNeighbors())
            {
                if (item.IsAlive == true) livesCount++;
            }

            if (this.IsAlive == true && livesCount <1)
            {
                //孤單死亡：如果細胞的鄰居小於一個，則該細胞在下一次狀態將死亡。
                this.IsAlive = false;
            }
            else if (this.IsAlive == true && livesCount >= 4)
            {
                //擁擠死亡：如果細胞的鄰居在四個以上，則該細胞在下一次狀態將死亡。
                this.IsAlive = false;
            }
            else if (this.IsAlive == true && (livesCount == 2 || livesCount == 3))
            {
                //穩定：如果細胞的鄰居為二個或三個，則下一次狀態為穩定存活。
                //this.IsAlive = true;
            }
            else if (this.IsAlive == false && livesCount == 3)
            {
                //復活：如果某位置原無細胞存活，而該位置的鄰居為三個，則該位置將復活一細胞。
                this.IsAlive = true;
            }
            else
            {
                // ToDo: 未定義的狀態? assert
            }
        }
    }

   1:  public class Cell //: Life

   2:  {

   3:      protected World CurrentWorld { get; private set; }

   4:      internal int PosX = 0;

   5:      internal int PosY = 0;

   6:      private const double InitAliveProbability = 0.2D;

   7:      private static Random _rnd = new Random();

   8:      public Cell(World world, int posX, int posY) //: base(world, posX, posY)

   9:      {

  10:          this.CurrentWorld = world;

  11:          // setup world

  12:          this.PosX = posY;

  13:          this.PosY = posY;

  14:          this.CurrentWorld.PutOn(this, posX, posY);

  15:          this.IsAlive = (_rnd.NextDouble() < InitAliveProbability);

  16:      }

  17:      public bool IsAlive { get; private set; }

  18:      protected IEnumerable<Cell> FindNeighbors()

  19:      {

  20:          foreach (Cell item in new Cell[] {

  21:              this.CurrentWorld.GetCell(this.PosX -1, this.PosY-1),

  22:              this.CurrentWorld.GetCell(this.PosX, this.PosY-1),

  23:              this.CurrentWorld.GetCell(this.PosX+1, this.PosY-1),

  24:              this.CurrentWorld.GetCell(this.PosX-1, this.PosY),

  25:              this.CurrentWorld.GetCell(this.PosX+1, this.PosY),

  26:              this.CurrentWorld.GetCell(this.PosX-1, this.PosY+1),

  27:              this.CurrentWorld.GetCell(this.PosX, this.PosY+1),

  28:              this.CurrentWorld.GetCell(this.PosX+1, this.PosY+1)})

  29:          {

  30:              if (item != null) yield return item;

  31:          }

  32:          yield break;

  33:      }

  34:      public void OnNextStateChange()

  35:      {

  36:          int livesCount = 0;

  37:          foreach (Cell item in this.FindNeighbors())

  38:          {

  39:              if (item.IsAlive == true) livesCount++;

  40:          }

  41:          if (this.IsAlive == true && livesCount <1)

  42:          {

  43:              //孤單死亡：如果細胞的鄰居小於一個，則該細胞在下一次狀態將死亡。

  44:              this.IsAlive = false;

  45:          }

  46:          else if (this.IsAlive == true && livesCount >= 4)

  47:          {

  48:              //擁擠死亡：如果細胞的鄰居在四個以上，則該細胞在下一次狀態將死亡。

  49:              this.IsAlive = false;

  50:          }

  51:          else if (this.IsAlive == true && (livesCount == 2 || livesCount == 3))

  52:          {

  53:              //穩定：如果細胞的鄰居為二個或三個，則下一次狀態為穩定存活。

  54:              //this.IsAlive = true;

  55:          }

  56:          else if (this.IsAlive == false && livesCount == 3)

  57:          {

  58:              //復活：如果某位置原無細胞存活，而該位置的鄰居為三個，則該位置將復活一細胞。

  59:              this.IsAlive = true;

  60:          }

  61:          else

  62:          {

  63:              // ToDo: 未定義的狀態? assert

  64:          }

  65:      }

  66:  }

這裡開始應用到 OOPL 第一個特性: 封裝。從程式碼可以看到，主要的邏輯都被包在裡面了，就 Game Of Life 裡提到的四條規則。

程式這樣寫起來，比那些作業的標準答案看起來舒服多了吧? 雖然行數多了一些，不過看起來比較有 OO 的樣子了。當然只是看起來爽是沒用的，這樣的架構，到目前為只除了邏輯清楚一點之外，還看不到其它很明顯的好處。不過當這個規責稍微複雜一點，OOPL的優點就會被突顯出來了。

下回，把題目做點變化，再來看看程式該如何調整…   ((待續))

--
附件: 範例程式碼

[前言]

好久沒寫點自己覺的有內容的東西了... 最近 code 寫的少，實在沒有什麼了不起的新技術可以分享，而 thread 那種 "古典" 計算機科學的東西也寫的差不多了.. 就懶了起來。

雖然沒新技術好寫，不過老狗玩的把戲還是能榨出點渣的... 很多人都熟新技術，可以寫出很炫的程式，不過也常看到程式的結構真的是亂搞一通的... 所以我打算寫些 [設計案例] 的文章，舉一些我實作過的案例，說明什麼樣的問題可以用什麼方式或技術來解決。其實我想寫的就是像 design patterns 那類的東西，只不過我程度還差的遠，只能稱作 "案例" ... Orz

----------------------------------------------------------------------------------

最近 facebook 上有一些小遊戲，不知道在紅什麼... 突然間大家都在玩，就都是些模擬遊戲，像是開心農場、My FishBowl … 之類的，你要在裡面種東西或養魚，條件充足就會長大，收成等等... 然後透過 Facebook API 可以跟別人互動的遊戲。看到這類的 GAME，不禁想起過去在唸書時，幾個經典的作業題目，其中一個 [生命遊戲] (Game of Life) 就是這種 GAME 的始祖...

在 Wiki 找的到這段介紹:

http://zh.wikipedia.org/zh-hk/%E7%94%9F%E5%91%BD%E6%B8%B8%E6%88%8F

生命遊戲（Game of Life），又稱生命棋，是英國數學家約翰·何頓·康威（John Horton Conway）在1970年發明的細胞自動機（cellular automaton，也翻譯成「格狀自動機」）。

它最初於1970年10月在《科學美國人》（Scientific American）雜誌中馬丁·葛登能（Martin Gardner）的「數學遊戲」專欄出現。

1970… 我還沒出生... Orz, 不過, 這麼一個古老經典的問題，找的到一大堆範例程式，或是作業解答。清一色是用 C 這類配的上它的年紀的程式語言寫的，就算有 JAVA 版，大概也是換湯不換藥... 這四十年程式語言及軟體技術的進步，寫這種程式總該有點改變吧?

這篇我想寫的，就是這樣的問題，配合現在的 .NET / C#，能怎麼寫它? 這年代的軟體開發技術，對這種古典的程式能發揮什麼效益?

(警告: 剛好要交作業的人，可千萬別用我的方法交出去啊... 你的助教看不懂可能會給你零分...)

先找個範例來看看... 為了不讓過多的畫面處理程式碼，干擾到主程式的架構，我特地找了兩個 console based 的範例:

Java 版:
http://tw.myblog.yahoo.com/dust512/article?mid=25&prev=28&next=-1

多語言版 (C, Java, Python, Scala):
http://caterpillar.onlyfun.net/Gossip/AlgorithmGossip/LifeGame.htm

這... 這就是典型的 "Java 版 C 程式碼" 的範例... 用 Java 來寫只寫這樣，有點用牛刀的感覺... 新的開發環境強調這幾項:

1. 物件導向 (封裝，多型，動態連結... etc)
2. 多執行緒
3. 其它語言特色 (這次會講到的是 yield return)

這些技術怎麼套進這程式? 先來看看這遊戲有幾個障礙要克服吧。遊戲的規則簡單明瞭，借轉貼上面第二個範例的說明:

生命遊戲（game of life）為1970年由英國數學家J. H. Conway所提出，某一細胞的鄰居包括上、下、左、右、左上、左下、右上與右下相鄰之細胞，遊戲規則如下：

1. 孤單死亡：如果細胞的鄰居小於一個，則該細胞在下一次狀態將死亡。
2. 擁擠死亡：如果細胞的鄰居在四個以上，則該細胞在下一次狀態將死亡。
3. 穩定：如果細胞的鄰居為二個或三個，則下一次狀態為穩定存活。
4. 復活：如果某位置原無細胞存活，而該位置的鄰居為三個，則該位置將復活一細胞。

以前我最討厭寫這種程式了，這種程式寫起來就跟 Regexp 一樣，是 "write only” 的 code… 怎麼說? 程式寫好後，可能自己都看不懂了，因為邏輯被切的亂七八糟... GAME 裡可能同時有好幾個細胞，每個都有獨立的規則，不過程式卻是一個主迴圈，每次執行每個細胞的一小段邏輯... 程式的流程就這樣被切碎了... 我打算用C#的 yield return, 解決這邏輯破碎的問題。

第二個障礙，就是這類程式，某種程度都是隨著時間的進行而跑的，比如上面的條件都是 "下一次狀態" … 把每次狀態改變定義一個時間 (比如一秒)，這就是個 realtime 的模擬程式了。如果有的細胞是一秒改變一次狀態，有的是兩秒，有的是五秒... 那就傷腦筋了... 你的程式會被切的更破碎... 這些每種細胞特殊的部份，我打算用 OOP 的多型來解決。

最後，這種很明顯是 "並行" 的問題，照道理來說，用多執行緒是最適合的了。不過隨便也有成千上萬個 "細胞" 在成長，每個都來一個 thread 養它，再高級的 server 都撐不住吧? 這邊會來探討一下，怎麼用執行緒相關的技巧，來解決這問題。

--------------------------------------------------------------------------------------

寫到這裡，突然覺的這題目好大... Orz, 搞不好這幾篇要撐幾個月才寫的完... 至少有個題材好寫，等到我生出第一個 sample code, 就會有下一篇了... 如果有同好也想試試看的，也歡迎分享看看你的 code… 只不過我沒像 darkthread 有本錢提供獎品... 哈哈 :D

先寫在前面，這篇不是什麼技術的探討或是評論，純脆是我個人看到這消息的想法而已。很久沒貼些軟體相關的文章了，最近比較少在動手寫 Code, 自然就沒什麼新題材好寫 @@，不過這兩天倒是看到一個蠻令人興奮的新聞，就是:

JPEG XR 已經正式通過 ISO 標準了!!

http://jpeg.org/newsrel26.html
http://blogs.msdn.com/billcrow/archive/2009/07/29/jpeg-xr-is-now-an-international-standard.aspx

JPEG 應該已經無人不知，無人不曉了吧? 不過當年還是有朋友鬧過笑話... 曾有人正經八百的來問我

"什麼是 [結合照片專業群組] 啊???" 就是 JPEG 啦 (無聊的話看一下底下的題外話)

我還丈二金剛摸不著頭腦，把他在看的整篇文章拿過來看，才晃然大悟他到底在問啥 =_= ... 原來是 "JPEG: Joint Photographic Experts Group”的縮寫... 當然類似的 MPEG (Moving Picture Experts Group) 也碰過類似的笑話... 無聊 GOOGLE 一下，竟然還查的到一篇範例...

http://support.microsoft.com/default.aspx/kb/235928/zh-tw

My God… 這翻譯真是比之前碰到了 "註冊傑克" 還絕 XD...

之前其實沒特別注意這些標準，曾經有印像的就是用 wavelet 壓縮方式的 JPEG2000... 嘗試取代 JPEG，也取得 ISO 的標準化，不過一直沒達成它的目的，只在特定領域還有應用空間。兩年前 Microsoft 隨著 Vista / WPF 推出 Windows Media Photo 的格式，後來為了讓它成為標準，換了個叫沒有 MS 色彩的名字: HD Photo, 最後變成現在的 JPEG XR ..

我是在兩年前，隨著 .NET 3.0 推出 WPF，剛好自己用的 CANON 相機的 RAW FILE 又被 WPF 支援，所以開始研究相關的 API 及 support .. 在關於 HD Photo 眾多報導中，有個觀點是我相當認同的。找不到較具代表性的消息來源，我就憑記憶寫一下，大意是:

隨著技術進步，未來影像設備 (如印表機，掃描器，顯示器等等) 的色彩表現能力及色域會遠超過 JPEG 格式的範圍 (現在就是了)，因此儲存格式支援的動態範圍 (dynamic range) 越高，對於影像的長期保存越重要。

這就是處女座的龜毛個性啊... 衝著這個看法，我從 Canon PowerShot G2 時代開始，我就試著盡量用 .CRW 格式 (CANON RAW) 來保存相片，而不是用 JPEG。後來換了 Canon PowerShot G9，正好 WPF 出來，我就開始改用保存 .CR2 檔，而另外轉一份 JPEG 檔來作一般用途 (畢竟 JPEG 還是方便的多)。不過一張照片花掉 15 ~ 20mb, 保存起來壓力還真不小 =_=

現在看到 JPEG XR 的標準化，正好是我要的東西啊 :D   我需要的正是個能妥善保存這些影像資料細節的方式，同時能讓我輕鬆愉快的使用，不用耽心工具支不支援，或是其它五四三等問題困擾...。這些問題對阿宅來說，一點都不困難，有一缸子的工具辦的到，不過... 如果隨變看個照片，或是要 COPY 給家人朋友看，還要動用一堆雞絲，那也太辛苦了一點... 能有個通用的標準格式及大廠背書，那是再好也不過了 :D

所以，接下來要做什麼? 我突然慶興我一直都有留著這幾年拍下來的 RAW file (.CRW / .CR2) 檔案... 該是替我的歸檔程式翻新的時後了，下一步是開始嘗試用 .WDP 來取代現在放兩份 RAW + JPEG 的方式...

自從過年時換了 SERVER 的作業系統，加上過年前 NOTEBOOK 掛掉換 X40 + SSD 之後，這幾個月都陷在東換換西調調的狀態中 @_@, 好在換了 2008 之後，有 Hyper-V 的幫忙，問題簡化不少...。不過今天要講的倒是很不起眼的小東西: SVN (Subversion)。

SVN 這種版本控制系統，通常是用來作程式碼的版本管理。也對啦，除了軟體開發之外，其它場合好像也不大需要這麼複雜的版本機制。不過這類系統弄多了，平常在非軟體開發的場合，也發現其實很多時後都有檔案版本問題要處理。像是平常的文件 (WORD)，簡報 (PPT) 等等，都會作好一份通用的，碰到 A 客戶就改一改拿來用，B 客戶再改一改... 這不就是 brench / merge 之類的問題嘛? 所以我一直在找這樣的 solution，看看有沒有適合一般使用的。不過到現在，也換了好幾種作法，歷年來試過的作法有好幾種:

1. VSS (Microsoft Visual SourceSafe 5.0)
   
   這個有用過的人，看版本號碼就知道有多古老了… 不過真正在用是 6.0 版開始。因為工作上會用的到，就順便拿來用了。它的好處是很簡單，搞懂它的邏輯就很容易上手。架設也簡單，完全是 File Based, 不需要架設專用的 Server。不過這也是後來換掉它的原因之一。
   
   它的使用方式，是以嚴格的控制為主要邏輯。什麼意思? 意思是你不能隨意更改檔案，要開使改檔案之前，要先 check-out 才能開始改。這樣的邏輯就是要避免未來一連串的版本衝突 (conflict) 及合併 (merge) 帶來的問題。 以軟體開發的角度來看，這樣的作法還不錯，整個團隊的開發是值得這樣作的。不過拿來管理個人檔案的話，就太過頭了。個人檔案不大會發生 LOCK 的問題，就是我改你也改，最後存檔總會有一個人的資料被蓋掉... 不過，如果我是大老闆，有十幾個秘書在幫我打雜的話就難說了 [H]
   
   
2. VSS (Windows Volume Shadow Copy Service)
   
   Visual Source Safe 用了之後，發現障礙多於它帶來的優點 (以處理一般文件而言)。主要的缺點是，VSS 透過網路 / Internet / VPN 使用的速度實在是龜到可以，雖然後來 Microsoft 推出了 LAN Boost Service (還是很慢)，也另外推出了 HTTP / Web Service 的存取方式 (只能透過 Visual Studio) 速度也不快。另一個缺點是一定要先開 VSS Explorer / Visual Studio, 我不過只是想開個 WORD 檔啊...
   
   所以後來換了另一個角度找 solution, 就試用了 windows 2003 內建的 VSS (Volume Shadow Copy Service), 替代版本控制用的軟體。它是做在 File System 層次上的機制，用了 Copy On Write (COW.. 這是縮寫，不是在罵人...) 的方式，做版本的差異控制。因此只要把檔案放在開啟 VSS 的磁碟機，完全不用更改任何使用習慣..。
   
   但是太自動的東西還是不適用。這種作法主要的問題在於版本太不精確了。VSS 仰賴定期作快照 (snapshot) 來作版本的管理。定期做的快照，留下來的版本很可能是無意義的，你也無法針對特定檔案的特定版本作註記 or 回複... 另外自動的快照也無法選則那些檔案要進版本，那些要退出。總之一切全自動，沒有什麼好選的。很簡單，但是功能也很有限。
   
   不過即使如此，一般情況下也夠用了，操作也夠簡單，當作第二種保護機制也不錯。這個 solution 我也用了好一陣子...。
   
   
3. TFS (Team Foundation Server)
   
   老實說，連一般小型軟體開發，用到 TFS 都太肥了一點，自己的檔案管理用到這個真是太離譜了... 哈哈，因此這個 solution 只是閃過念頭而已，跟本沒實際裝起來試過。用這個方案，工具會是個大問題... 用的時後得開個 Visual Studio, SERVER 還得裝一大票軟體 (IIS, TFS, SQL + Reporting, SharePoint Team Service, AD…)
   
   
4. USB DISK + PortableApps
   
   其實這個算不上是個 SOLUTION，只不過順便把它列上來，待會說明用。某次無意間，同事告訴我 PortableApps.com 這個工具，它是個灌在 USB 隨身碟上面的工具 & 一些綠色軟體，有自己專用的 "開始" 選單，方便你插上隨便一台電腦，就把它當作你自己的 PC 一樣使用... 老實說還不錯用 (Y)，我就試著用一陣子，把所有個人相關的資料都移到上面了。現在的工作環境有點複雜，公司一台 PC，家裡一台 PC，偶爾還需要用 notebook 去客戶那邊簡報 (咳，就是我那台只有 8GB SSD 的 X40，正好沒地方放檔案)
   
   用了一陣子還不錯，不過碰到的又是很常見的問題: 檔案掉了怎辦? 備份問題? 讀寫速度問題? Flash Disk 寫入次數限制問題... 不外乎常備份，每天一份 ZIP 檔，用苦力作好版本控制…
   
   
   
5. USB DISK + SVN
   
   最後，就是現在用的方案了... 主要是補 (4) 的不足: 一般的定期 ZIP 備份就跟快照一樣，事後要追出變更其實很麻煩，每次變更想加個註解又更麻煩了。當然搭配 Visual Source Safe 這種工具，把 Working Folder 指到 USB DISK 上就可以兩全齊美了。
   
   不過使用便利則是另一個問題，我希望能夠找個無腦一點的工具，不需事先 check-out (lock) 的動作就可以開始編輯，改完再決定 check-in (commit) 或是 undo (revert) 的模式最好。用了 USB DISK 就是希望能拔來拔去，如果必需配合特定工具 & 要即時連上 SERVER，那就有點麻煩... 想看看，當我 USB DISK 插到 NOTEBOOK 帶到客戶那邊去，都按兩下打開 PPT 在簡報了，臨時要改幾個字，用 VSS 的話，我得關掉 PPT，打開 VSS，CHECK-OUT，打開PPT，修改...
   
   所以後來的首選就變成 SVN 了。SVN 因應 internet / open source project 的開發模式，採取的就跟 Microsoft 是不同的策略，就是先改再說。SVN 賭你不會多人同時編同一個檔案，就算會，也不會編同一段 code … 真的碰到就再人工處理吧。另外它支援各種不同的 protocol, 透過 internet 這種連線來使用，效能也不會很糟糕...

到目前為止，我用的就是 (5) USB DISK + SVN 這種 solution, 老實說越用越覺的它不錯 (Y)。SVN 我還是個新手，應該輪不到我來介紹他的特色吧 XD，不過我還是挑幾個特別的地方介紹一下，這些是我用它的主要原因啊...

1. 操作邏輯合適
   
   SVN 是 CVS 的接班人，它先天就繼承了 CVS 的特性: 就是適用 open source 的開發團隊。Open Source 的開發團隊跟一般的開發團隊有什麼差別? 一般商業開發都是正職的工作，很固定且很密集的進行開發及變更，因此像 Microsoft Solution (VSS / TFS) 那種要事先 lock 的機制會比較有效率。不過 open source project 就反過來，業餘的比例比較高，而且人都散布在世界各地，如果真正用 LOCK 的機制大概會哭出來吧...。我要改的檔案被你 LOCK 住了，不過我又不知道你是誰? 除了等就沒辦法了...。
   
   因此 SVN 先天就是以這樣的觀點來設計: 你先改了再說，改完就 commit 。反正只要沒人跟你改同一個檔案就沒事... 如果運氣真的不好，那這個人不要跟你改同一段 code 也沒事，直接 merge 就好... 只有真的很背的時後，有人跟你改同一段，那麼後 commit 的人就要負責處理 merge 的問題。不過機率很低嘛 (沒錯，尤其是只有我自己用的時後)，你可以不用管它...
   
   過去用 VSS 常碰到這種情況: 原本只是開個文件起來看 (READ)，跟本沒想要去改它，就沒有先作 check-out 的動作了。不過看到一半發現內容有誤，想要修正時... 問題就來了。以 WORD 來說，已經開起來才去 check-out 檔案的話，WORD還是會認為檔案是唯讀的... 除非你關掉 WORD 再開啟一次才有用。不過這麼一來思緒都被打斷了...。
   
   當然，還是一樣，正規的開發動作還可以要求，一般的文書處理要求到這樣就有點過頭了。因此 SVN 這樣的邏輯就佔了點優勢，我最常碰到的案例就是: 要出門開會，把 USB_DISK 拔出來帶走。開會過程中 (在外面，沒有網路連線) 修修改改 PPT 的內容，回到公司後直接在 NB 或是把 USB DISK 插回 PC，再用 SVN 作 commit 的動作...。
   
   
2. SERVER 的資訊跟著目錄
   
   有些工具 (像是 TFS)，你的工作目錄對應到那個 SERVER，是工具在維護的 (TFS 的 workspace)，這時搭配 USB DISK 可能會在不同的電腦 (可能是我的 PC，也可能是我的 NOTEBOOK，甚至是帶回家裡用)。一般把設定綁在工具上的作法就很頭痛，因為好幾台都要設成一樣的，而且 USB DISK 還有可能每次的磁碟機路逕都不大一樣...
   
   我用的工具是小烏龜 (TortoiseSVN)，它的設定就是在每個目錄下放個 .svn / _svn 的子目錄，檔案總管按右鍵叫出 SVN 的選單後，藏在裡面的設定就自動套上來了。這種操作模式，剛好對於我的用法 (USB_DISK) 很方便...
   
   
3. 更精確，更有效率的 "備份機制"
   
   現在隨身碟廠商，都很愛在商品上加一些小工具，有的有壓縮，有的有密碼保護... 不過 USB DISK 很容易掉，所以所有廠商都不會忘記附上一個備份工具。連我前面介紹的 PortableApps.com 都有附一個 ( 7-ZIP + SHELL )。不過這些備份工具都有個通病... 它就真的只是 "備份" 而已，是讓你心安的。使用時機是你自己要勤勞點，記得每天按 BACKUP。要還原回來，通常就是整支 USB DISK 的內容都還原回來了，如果你只想要還原某幾個檔，或是只要查看過去備份的某個檔，那你得點好幾下滑鼠，甚至是要把整個備份解開才看的到。
   
   另一個備份問題是，每次都是 FULL BACKUP ... 雖然有些工具作的比較好，有差異備份 ( PortableApps.com 就有提供 7-ZIP 的差異備份)，不過不還原還好，一旦要把舊資料撈出來也是很辛苦。當然這些並不是備份工具的錯，備份本來就是作這些事。中間有落差的地方在於 USER 需要的是一個歸檔的機制啊，除了備份也需要調閱舊的版本內容。這時版本控管工具，正好就成為 USB DISK 在 PC 上的第一線 "備份資料庫" 了。當你在 check-in / commit 時，不自覺的就在版本系統內放了一份備份了，不放心的人可以再啟用像 VSS (Volume Shadow Copy Service) 或是定期壓 ZIP 這類一般的備份機制作第二層保護，就很足夠了。
   
   這裡的重點倒不是備份安不安全啦，而是這樣的操作方式，很自然的就會在 SVN Repository 內留下一份內容，同時也方便你替這個版本作註記，未來要調閱，甚至是比對內容差異都很容易...
   
   
4. 異地存取
   
   USB DISK 雖然很方便，也可以隨身攜帶，但是我就是會常常忘掉它... 常常忘了拔就出門... 在外面如果還要存取我的 USB DISK 的內容，有網路的話，版本控制系統也很好用。我用的 SVN SERVER 是 Visual SVN，它就有個很簡易的 WEB 介面，真的忘了帶還可以連回我自己的 PC，把檔案下載回來。
   
   如果用的電腦有灌 SVN CLIENT，那你還可以做些基本的操作...。這套比起來就比 VSS 強的多。VSS 完全是 file system base, 透過遠端的操作必需先用網芳之類模擬 file I/O 的方式，效能很糟糕... 雖然 2003 年左右 Microsoft 替 VSS 加其了很多功能，像是 LAN Boost Service (我搞不懂它怎麼做的)，或是替 VSS 加上 Web Service Interface (可以透過 HTTP)，不過效果都不盡理想。
   

這些功能加一加，就是我現在在用的個人檔案管理方案了啦。家裡有台現成 SERVER，很多問題就更好解了。這套作法正好给有需要的人參考看看，如果你用了有什麼心得，或是有其它更好的用法也歡迎分享 :D

果然這個什麼東西都上網的年代，要三不五時的 GOOGLE 一下自己，才會知道那些網站把你的八卦跟內幕爆了出來... 不過應該沒啥週刊記者對我有興趣吧? 哈哈。在 GOOGLE 自己名字時，倒是意外發現，之前投稿的文章，又有一篇被拿來登在網站上的精選文章了 :D

特此留念一下 :D

http://www.runpc.com.tw/content/main_content.aspx?mgo=176&fid=E02

--

順便整理一下懶人包:

另一篇精選文章 [RUN!PC 精選文章 - 生產線模式的多執行緒應用]

過去投過的系列文章 (multi-threading programming using c#):

2008/11. 生產線模式的多執行緒應用
2008/09. 用ThreadPool發揮CPU運算能力
2008/06. SEMAPHORE在ASP.NET的應用
2008/04. 以ASP.NET開發同步WEB應用程式

繼承 (inheritance) 是物件技術的核心，就是這個特性提供了 OOP 絕大部份的特色。這東西被拿掉的話，OOP就沒這麼迷人了。繼然談到了 ORM，就不能不來看看 R(關聯式資料庫) 怎麼被對應到 O(物件)，同時還能處理好繼承關係。

RDBMS 連基本的物件 (Object Base) 都不支援了，更別說物件導向 (Object Oriented) 了。因此要搞懂 ORM 及繼承的關係，就得先瞭解基本的 OO 是怎麼實作 "繼承" 這個動作。這些知識是古早以前學 C++ 時唸到的，現在的 CLR 不知道有沒有新的作法? 不過應該大同小異吧! C++ 主要是靠 virtual table 來實作繼承關係，當子類別繼承父類別時，父類別定義的 data member 跟 method 就全都遺傳到子類別身上了，這動作就是靠 virtual table 作到的。細節我就不多說了，有興趣的讀者們請先上網找找相關資訊看一看。

ORM 的運氣好多了，只要處理資料的部份。因此前一段提到的 virtual table 如果要拿來應用也會簡單的多。virtual table 可以很直覺的想像成是 DBMS 裡 table schema 的定義，而一個物件 (instance) 的 virtual table 資料，正好就對應到該 table (DBMS) 的一筆資料。這正好是 ORM 基本的動作。大部份 OO 的書都會說，繼承就是 " Is A " 的關係。在資料上則是子類別擁有父類別所有的欄位定義。這很容易對應到資料庫的正規化，該如何切割資料表的規責。你可以切開靠 PK / FK 再併回來，或是直接反正規化讓它重複定義在多個 TABLE... 事實上，兩大 ORM (EF & NH) 都歸納出三種作法，後面來探討一下彼此的差異...

再來看看繼承關係，假設父類別 class A 對應到 table A, 那麼衍生出的子類別 class B 對應的 table B, 則應該要包含所有 table A 定義的欄位才對。從這點出發，就帶出了第一種作法: 就是把 table A 所有的欄位都建一份到 table B (註: table per concrete type)。

不過這樣看起來有點蠢，DBMS 熟悉的人也許會採另一種作法: 沒錯... table B 只要留個 foreign Key, 指向 table A 的 primary Key，需要時再 join 起來就好了，這是第二種作法 (註: table per type)。

唸過 DBMS 的人都還記得 "正規化" (normalization) 跟 "反正規化" 吧? 切割過頭也是很麻煩的，因此有第三種作法逆其道而行，就是建一個 table 給所有的子子孫孫類別共用。因此 table 需要的欄位，就是所有的子類別的所有欄位集大成，通通都建進來... 不用的話就空在那裡，這是第三種作法 (註: table per hierarchy)。

這三種作法，在 Entity Framework (以下簡稱 EF) 或是 NHibernate (以下簡稱 NH) 都有對應的作法，只不過名字不大一樣... 這篇 ADO.NET team blog 借紹的還不錯，可以參考看看。這三種方式，在 EF 裡的說法分別是 (括號裡是 NH 的說法，參考這篇: Inheritance Mapping):

• Table per Hierarchy (NH: Table per class hierarchy)
• Table per Type (NH: Table per subclass)
• Table per Concrete Type (NH: Table per concrete class)

事時上，處理方式大同小異，不外乎用三種不同的對應方式，來處理物件繼承關係。這些不同類別的物件彼此有繼承關係，對應到 TABLE 的方法不同，各有各的優缺點。其實 ADO.NET team blog 講的都很清楚，我就不再多說，簡單列張比較表:

[未完待續] to be continue…

這次為了能順利的學好 Entity Framework，花了不少工夫在研究它的作法。不過有一大半不是在 Entity Framework 本身，而是在 C# 的一些特別的語法跟 LINQ 身上...。也因為這樣，我深切的體認到一個 ORM 技術能不能成功，其實都是在 Hosting 這個 Framework 的環境夠不夠成熟...。

不過在摸索的過程中，找到的資訊都是片斷的，每一篇都是講實作，範例程式，操作步驟... 等等，而當時我最需要的反而是幫助我決定，Entity Framework 到底值不值得我押在上面投資五年開發計劃使用的 ORM 技術? 它跟 NHibernate (考慮中的另一項 ORM framework) 的優缺點為何? 未來發展的優缺點又是什麼? 架構上的差異在那? 另外 Linq to SQL 呢? 這些較偏架構性跟本質的討論及比較資訊，反而少之又少...。

雖然最後還是研究了些心得出來，不過實在是不想寫那些到處都看的到的實作，就來寫點不一樣的吧。第一篇會先寫寫 ORM 的背景知識，還有 Entity Framework 跟 C# 的語法是如何魚幫水，水幫魚，如何解決了過去 ORM 用起來都不大對勁的問題...。

繼續長篇大論前，先老王賣瓜一下。雖然我碰過的 ORM framework 不多，不過相關的理論跟技術則碰了不少。撇開大學就在研究的 OOP 不談，研究所的指導教授就從 SmallTalk 開使教... 兩年的專題研究都是 OODB (物件導向資料庫)，相關論文也看了一堆。出來工作後又有幸用了幾年的 TAMINO (一套 native xml database), 之後又花了很多時間，在 SQL 2000 上面建立起一套 Object <-> XML <-> Database，類似 ORM 的 Framework ...

不過這麼一路下來，都沒有覺的簡單又可行的方案。除了上面講的是我親自參與過的之外， M$ 其實也發表過幾個類似的技術，像是 Typed DataSet 就是個較接近的產物。 Typed DataSet 其實有點接近現在的 Entity Framework 了。DataSet 就等同於 Entity Container / ObjectContext, DataTable 大致就等同於 EntitySet, 而 DataRow 則等同於 Entity, Relation 則大致等同於 Entity Framework 的 Navigation Property.... 不過用起來還是到處都看的到 DataSet 的影子，感覺血統還不夠純正...

不過現在的 Entity Framework 不一樣了，感覺就已經往實用的領域邁進了一大步! 並不是說 Entity Framework 做的很好 (以成熟度來說, NHibernate 比目前的 Entity Framework 好的多), 而是跟 Entity Framework 搭配的技術都成熟了。一套 ORM 要成功，必要的條件很多啊... 實作上的角度看來，我覺的重要的有這幾項:

1. 要有優良的 Object / Relationship Mapping 機制、作法、工具等等
2. Framework 本身的擴充及自訂的能力要夠
3. 要有效的解決以物件角度思考的查詢 (QUERY) 問題
4. "物件" 要看起來像 "物件"，不是 "資料"
5. 處理資料庫典型的問題，效能跟便利性不能跟直接操作 DB 差太多
6. 你的牌子夠不夠響亮... (這是心理因素而已... 哈哈)

這些是深切的體認。不然的話 ORM 的東西跟本不難啊，以功能來說，Typed DataSet 其實就解決一大半實際的問題了。先來看看物件導向幾個關鍵的核心技術是啥?

1. 封裝 ( Encapsulation )，抽像化型別 (ADT, Abstract Data Type)，資料 (Data) 跟行為 (Behavior) 能夠綁在一起
2. 繼承 ( Inheritance )
3. 多型 ( Polymorphism )

以這樣 "物件" 的關點來看，M$ 在 Entity Framework 之前的資料庫技術其實都不合格。先來看看資料庫存取技術，如果能搭配這些物件技術，能有什麼樣的改進?

[封裝]
這就沒啥好講的了。物件技術有很好的封裝機制，public / protected / private 等等 scope modifier 就能提供很棒的封裝機制。不過資料庫很難做的好，資料庫的那套頂多叫作安全機制 (security) 或是授權機制 (authorization), 不是封裝 (encapsulation) ... 真正的封裝不是看你是那個帳號決定能不能讀資料? 而是你是那個 SCOPE 的程式，能不能存取封裝起來的內部資訊。DBMS 對於資料的控制能力很有限，不外呼 Key, Constraint, Relationship / Foreign Key 等等。像加解密，正規運算式 (regular expression) 等等，對 DBMS 來說就太複雜了。更複雜的封裝機制單靠 DB 就很不實際... 無奈在沒有 ORM 的前題下，這些問題則是直接曝露在你的程式碼每個地方...。換句話說，如果 ORM 能提供良好的封裝機制，ORM 就能取代掉目前的 Data Access Layer ，成為 APP 存取 DBMS 的主要 API 。

順便吐個苦水，也因為 DBMS 對於資料的控制能力有限，維護的 APP 總是碰到這種問題，就是錯誤的資料總是有辦法鑽進資料庫裡面。不為什麼，只因為 DBMS 本身擋不下來，而 Data Access Layer 又不夠爭氣到足以扛下這重責大任，最後只能靠 APP 自身的開發人員，靠紀律跟自律，還有良心來作好這層把關的動作... -_- 如果有套像樣的 ORM 能夠卡在這個位置，光是資料內容的把關，就是一大進步了。

[繼承]
繼承跟資料庫有什麼關係? 其實 ORM 如果能有效的把繼承的功能跟資料庫整合起來，也是很嚇人的。舉例來說，部落格支援文章，相片等等不同的內容，但是它們都要有一致的抽像行為，如新的內容要能夠訂閱 (rss subscription)，要能夠有標簽 (tagging) 等等共通的功能，在物件技術我們會很直覺的用繼承來做到。定義 BlogContent 類別，把這些邏輯擺上去。之後再分別衍生出 ArticleContent / PhotoContent 等類別，把差異的實作補上去就完成了。不過同樣的概念別想直接套用在資料庫上，你的腦袋得負責這兩者之間的對應。

懂的這麼多的工程師很難找啊... 去那裡找這種人來寫 APP ? 其實搞懂這些也不難，C++ / C# 在解決這類問題，只是很簡單的利用到 virtual table 就搞定了。換到 DBMS，就把 virtual table 的資料結構套到 database schema 就可以。不過說來簡單，能夠搞懂這些，還能精確的實作出來的人不多... 真的作出來還會被嫌:

"它ㄨ的，誰設計的 table schema ? 亂切一通害我 T-SQL query 這麼難寫..."

嗯，沒事，藉機吐吐苦水。主要要表達的就只有一個，繼承關係要對應到資料庫上面，也是挺麻煩的一件事。Entity Framework / NHibernate 就都提供了三種對應的方法。這三種切割對應的方式，要選那一種? 這又是門學問... Orz, 以後再說。

[多型]
這個就更玄了。多型是建立在繼承的基礎上，不管你是什麼類別的 instance, 多型的機制可以在父類別的角度，對所有各種衍生類別的物件，一視同仁的操作。而在這統一的前題下，每種類別的物件又可以一國兩制的各自為政... (咳，這不是政治版...)。這樣的抽像程度就是資料庫遠遠所不及的。延序前面講的部落格內容的例子，你能想像這個 store procedure 該怎麼寫嗎?

"要寫一個 sp_update_blogcontent 的 store procedure, 如果 ID 指向的是 blog, 則要執行更新 HTML 的 code，如果是 photo, 則要更新存放圖檔的 BLOB 欄位..."

天那，在 DB 這個層次，寫這種 CODE 只能用很醜的 IF  ELSE 一層一層堆起來...，跟物件技術比起來，程式碼的描述及抽像化能力實在差太遠，在這層次能解決的問題複雜度很有限...。你如果是個聰明人，最好還是別在 DBMS 搞這些物件技術，會死人的...。比較好的作法是移到 APP 那層去作比較實際。

不錯，ORM 存在的原因又多了一個...。

所以，再回頭來看看，ORM真的要發揮它的效益的話，絕對不是只有用 "物件" 來代替 "資料" 而已 (還是老話一句，這樣的話用 Typed DataSet 就夠了)。至少對應出來的 "物件"，還能有效的應用到這些物件導向的特性，同時 ORM framework 還能替你維持這些跟資料庫的對應關係，這樣 ORM 技術才能真正發揮它的效益，那些被講到爛的三層式架構才不會在 DBMS 這層就破功了。

來看看比較具體的部份。這些物件技術的特點，C# 早在 2000 年，JAVA 早在 199X 年就有了，沒什麼了不起。不過當年的 ORM 實在難用的很。當時的 OOPL 就是缺了些東西，ORM 的程式寫起來限制一堆... 對應到資料庫的物件，用起來就是跟一般的物件差很多，這也不能用，那也不能用。

現在的 C# 就不一樣了，進化到足以解決這些語言的限制。來看看:

1. reflection, attribute:
   這個讓物件 (Entity) 可以寫的更簡潔，reflection + attribute 可以解決很多過去得繞一大圈才做的到的事。如 class 對應到那個 table, property 對應到那個 column 等等。
2. partial class:
   ORM 免不了有些 code generator 的搭配。有 partial class 可以讓程式搭配 code generator 更容易一點。
3. extension methods:
   現有的物件技術很難讓你在現有的 class 上去作擴充，而 extension methods 可以。
4. Linq
   這可是一大進步。過去 ORM 的目的就是想把 DB 的細節藏起來，無奈碰到 QUERY 的話什麼都藏不住，往往淪落到要嘛都直接用 SQL, 不然就是只剩幾種基本的 API 可以用，無法完全取代直接用 SQL 的查詢。不過 Linq 出現之後這情況就改觀了，雖然像報表那樣複雜大型的 QUERY 還是得直接下 SQL，不過一般 AP 內的查詢都可以直接用 Linq 搞定了

其它當然還有別的，不過我自己覺的這幾點是關鍵，至少可以讓現在的 Entity Framework 在使用 Entity 時，不會再跟一般的物件有什麼不同。大部份你可以應用在一般物件的技巧，也都能套用在 Entity 身上。第一篇碎碎唸的部份就先寫到這裡。後面會示範一下幾種打造你專屬的 Entity 用到的技巧。想看後面的讀者們請耐心等待 :D

無意間 search 我自己的名字，才發現這篇文章除了投稿到 RUN! PC 之外，原來還有刊在網站上的精選文章啊...

哈哈，暗爽一下，順道貼一下 link, 讓沒看到雜誌的網友們也有機會看一看在下的作品...