从模拟字符串型的枚举说起 [c#]_c#应用

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 那样简单，不但同一类型的顾客（例如白金会员）所能享受到的折扣随时会发生变化，而且同一的商品在不同的时期（例如促销期）的折扣也有可能不同，于是顾客最终所能享受到的折扣可能是个经过复杂运算的综合折扣。任何对变化因素的硬编码都会导致系统的僵化！我建议在阅读该文这部分内容时应以研究枚举的这方面特性为目的。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有