1. 有字符串型的枚舉嗎？

uk 在《關于枚舉的種種》中提到這樣一個問題：

枚舉的成員類型都是數值型的，如果想做一個字符型的枚舉有什么辦法？

    enum colors : string{
        red='#ff0000',
       
    }
在展開討論之前，我認為有必要搞清楚另一個問題，上面代碼中的 '#ff0000' 不是字符而是字符串，應改成 "#ff0000"，于是，uk 的問題也順利成章地改成“想做一個字符串型的枚舉有什么辦法”了。

很坦白地說，.net 并不支持這樣的字符串型枚舉。另外，也不是所有的數值類型都能作為枚舉的底層類型，枚舉的底層類型只能是整數類型，這意味著某天你想定義一個底層類型為 double 的枚舉，你將會收到編譯器的警告信。

uk 的代碼確實提出了這樣一種需求，colors 就像一個枚舉，但其成員的值是一個字符串，于是，我們很容易產生這樣一個疑問：是否能夠模擬出這樣一個枚舉呢？

2. 有辦法模擬出來嗎？

在寫任何代碼之前，讓我們首先思考一下，假如真有這樣一個 color 類，我們會怎樣使用它？以下是我想到的兩個用法：

1// code #01
2
3color c1 = color.red;
4string s1 = (string)c1;
5debug.assert(s1 == "#ff0000");
6
7color c2 = (color)"#00ff00";
8debug.assert(c2 == color.green);
首先，枚舉是通過其成員而不是構造函數來初始化的，正如上面代碼的第三行。于是，我們應該把構造函數設為私有，同時模擬一些枚舉成員并暴露出來：

// code #02

public class color
{
    private color(string value)
    {
        m_value = value;
    }

    private string m_value;

    public static readonly color red = new color("#ff0000");
    public static readonly color green = new color("#00ff00");
    public static readonly color blue = new color("#0000ff");
}
這樣，code #01 的第三行就可以工作了。值得提醒的是，red、green 和 blue 等成員的值都是不變的，為了不讓客戶代碼修改它們的值，我把它們設成 readonly（注意：它們不可以設為 const，你知道為什么嗎？）。另外，它們應該屬于 color 類而不是某個實例的，于是把它們設成 static。

接著，code #01 的第四行說明了 color 的實例可以強制轉換成字符串，這可以通過重載轉換運算符做到：

// code #03

public static explicit operator string(color value)
{
    return value.m_value;
}
與 code #01 的第四行對應的是 code #01 的第七行，它說明了字符串可以強制轉換成 color 實例，這也是通過重載轉換運算符做到的：

// code #04

public static explicit operator color(string value)
{
    switch (value)
    {
        case "#ff0000":
            return red;
        case "#00ff00":
            return green;
        case "#0000ff":
            return blue;
        default:
            throw new invalidcastexception();
    }
}
很明顯，并不是所有的字符串都可以轉換成 color 實例，所以，當客戶代碼試圖把一個含有非預期值的字符串轉換成 color 實例時就應該拋出 invalidcastexception 了。

誠然，有些人會對 code #04 很反感，因為它里面有一個 switch！當我們使用枚舉時，我們并不只是用它來進行一些值的轉換或者獲取其字面值，我們更希望用它來標識不同的情況或者類別，并根據枚舉實例的值來判斷屬于哪一情況或類別。換句話說，當我們決定使用枚舉時，我們就注定與條件語句結下不解之緣了。

最后，這里給出 color 的完整代碼：

// code #05

color#region color

public class color
{
    private color(string value)
    {
        m_value = value;
    }

    public static explicit operator color(string value)
    {
        switch (value)
        {
            case "#ff0000":
                return red;
            case "#00ff00":
                return green;
            case "#0000ff":
                return blue;
            default:
                throw new invalidcastexception();
        }
    }

    public static explicit operator string(color value)
    {
        return value.m_value;
    }

    public override string tostring()
    {
        return m_value;
    }

    public static readonly color red = new color("#ff0000");
    public static readonly color green = new color("#00ff00");
    public static readonly color blue = new color("#0000ff");

    private string m_value;
}

#endregion
或許有人會提出這樣一個問題：我們經常會對枚舉進行判等運算，但為什么 code #05 中既沒有重載 object.equals 方法，也沒有提供 == 和 != 運算符呢？細心觀察 color 的代碼，你會發現獲取 color 的實例只有兩種途徑：通過靜態只讀字段和通過強制轉換運算符，但無論你是如何得到 color 的實例，這些實例最終都是源自 color 內部的靜態只讀字段。換言之，通過這兩種途徑分別獲得的兩個 color 實例其實是同一個實例。

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));