3. 模擬方案有什麼問題嗎？
我相信 Color 在一定程度上能滿足需求，但我認為 Color 並不一定適合實際應用。回顧 Code #05，Color 既是枚舉也是資料載體。說它是枚舉，是因為我們刻意模擬成枚舉；說它是資料載體，是因為我們不僅以枚舉方式使用它，更需要成員背後代表的值。這意味著 Color 承擔的責任超過一個，違反了單一職責原則（SRP）。
我懷疑之所以對 Color 有這樣期望，或多或少受到《關於枚舉的種種》中「枚舉成員的值」部分影響，特別是「為什麼需要手動指定枚舉成員的值？」這個問題的答案。若真是如此，我必須為該文產生的誤導道歉。現實情況往往不像 Code #13 那樣簡單：不但同類型顧客（如白金會員）享受的折扣隨時變化，而且同一商品在不同時期（如促銷期）折扣也可能不同，顧客最終享受的折扣可能是經過複雜運算的綜合折扣。任何對變化因素的硬編碼都會導致系統僵化！建議閱讀該部分時以研究枚舉特性為目的。
另一方面，Color 作為資料載體確實弱得可憐。目前僅包含 R、G、B 三個通道資料，若想加入 alpha 通道會對程式碼產生多大衝擊？若希望分別提取 A、R、G、B 四個通道？若要實現 RGB 與 CMYK 間的資料轉換？這些問題足以讓人頭痛一周。但當你知道人眼能識別的顏色約有一千六百萬種，且都可透過 RGB 值描述並作為顯示器輸出依據時，滑鼠會不會指向瀏覽器右上角的叉叉？
很明顯，這裡給出的 Color 經不起時間考驗，於是我不禁思考：.NET Framework 究竟如何表達 Color？又如何滿足這些讓人苦惱的需求？
4. .NET Framework 又如何表達 Color 呢？
在 .NET Framework 中，與此需求相關的有 3 個：Color 結構、KnownColor 枚舉和 ColorTranslator 類別，都位於 System.Drawing 命名空間。
首先說說 KnownColor 枚舉，成員分兩類：一類是有名字的顏色，對應 RGB 值不變，如 Indigo 是靛藍；另一類是外觀項目顏色，對應 RGB 值隨使用者設定改變，如 InfoText 是工具提示文字顏色。
其次是 Color 結構，有許多靜態屬性，獲取與 KnownColor 第一類成員對應的 Color 實例。提供 FromKnownColor 和 ToKnownColor 方法實現實例與枚舉間轉換。作為資料載體，它包含 A、R、G、B 四個通道資料，實例判等相當於對這些資料判等，因此重載了 == 和 != 運算子。
說了這麼多，似乎還沒提到如何從 Color 實例得到 HTML 顏色值。現在讓 ColorTranslator 類別登場。該類提供 ToHtml 和 FromHtml 方法，實現 Color 實例與 HTML 顏色值字串間的轉換。
這三個東西的責任都很明確：需判斷某處是否用某種顏色時，無需比較 A、R、G、B 四通道資料，只需快而準的標識比較，KnownColor 枚舉恰好滿足；需操作顏色資料時，不想操作字串，Color 結構能輕易提取所需資料；在顏色資料與 HTML 顏色值字串間轉換時，不太需要枚舉做標識。但也可能結合三者一起使用，下例作為本文收尾：
// Code #06
string desktopColorValue = ColorTranslator.ToHtml(Color.FromKnownColor(KnownColor.Desktop));
