3. 模擬方案有什麼問題嗎？
我相信，Color 在一定程度上能夠滿足 UK 的需求了，但是，我認為 Color 並不一定能用到實際的應用中去。回顧 Code #05，Color 既是一個枚舉也是一個數據載體。說它是枚舉，是因為我們刻意把它模擬成枚舉；說它是一個數據載體，是因為我們並不僅僅以枚舉的方式來用它，我們更需要的是成員背後所代表的值。這意味著 Color 承擔的責任多於一個，違反了單一責任原則（SRP）。
我懷疑，UK 之所以對 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 方法用於實現它的實例和 KnownColor 枚舉之間的轉換。當然，由於它是一個數據載體，它包含了 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));
