何时使用枚举，何时用具有静态成员的类替换它们？

Question

我最近想到以下（示例）枚举

enum Color
{
    Red,
    Green,
    Yellow,
    Blue
}

......可以用看似更类型安全的类替换：

class Color
{
    private Color() { }

    public static readonly Color   Red      = new Color();
    public static readonly Color   Green    = new Color();
    public static readonly Color   Yellow   = new Color();
    public static readonly Color   Blue     = new Color();
}

使用“类型安全”，我的意思是如果 Color 则以下语句将起作用 是一个枚举，但如果 Color 是上面的类，则不是：

var nonsenseColor = (Color)17;    // works if Color is an enum

两个问题：

1) 此模式是否有一个被广泛接受的名称（将枚举替换为类型安全的类）？

2) 在什么情况下应该使用枚举，什么时候使用类更合适？

Answer 1

枚举非常适合轻量级状态信息。例如，您的颜色枚举（不包括蓝色）非常适合查询交通灯的状态。真实的颜色以及颜色的整个概念及其所有包袱（alpha、颜色空间等）并不重要，重要的是灯处于哪个状态。另外，稍微改变你的枚举来表示交通灯的状态：

[Flags()]
public enum LightColors
{
    unknown = 0,
    red = 1,
    yellow = 2,
    green = 4,
    green_arrow = 8
}

当前灯光状态可以设置为：

LightColors c = LightColors.red | LightColors.green_arrow;

并查询为：

if ((c & LightColors.red) == LightColors.red)
{
    //Don't drive
}
else if ((c & LightColors.green_arrow) == LightColors.green_arrow)
{
    //Turn
}

静态类颜色成员将能够支持这种多重状态，而无需额外的功能。

然而，静态类成员对于常用对象来说非常有用。 System.Drawing.Color 成员是很好的例子，因为它们代表具有模糊构造函数的已知名称颜色（除非您知道十六进制颜色）。如果它们被实现为枚举，那么每次您想要使用该值作为颜色时，您都必须执行类似的操作：

colors c = colors.red;
switch (c)
{
    case colors.red:
        return System.Drawing.Color.FromArgb(255, 0, 0);
        break;
    case colors.green:
        return System.Drawing.Color.FromArgb(0,255,0);
        break;
}

因此，如果您有一个枚举并发现您不断地执行 switch/case/if/else/whatever要派生对象，您可能需要使用静态类成员。如果您只是查询某物的状态，我会坚持使用枚举。另外，如果您必须以不安全的方式传递数据，则枚举可能比对象的序列化版本更好地生存。

编辑：
@stakx，我认为你在回应@Anton的帖子时也偶然发现了一些重要的东西，那就是复杂性或更重要的是，它对谁来说是复杂的？

从消费者的角度来看，我非常喜欢 System.Drawing.Color 静态类成员，而不是必须编写所有这些。然而，从制片人的角度来看，必须编写所有这些内容将是一件痛苦的事情。因此，如果其他人要使用您的代码，您可能会通过使用静态类成员为他们节省很多麻烦，即使您可能需要花费 10 倍的时间来编写/测试/调试。但是，如果只有您，您可能会发现根据需要使用枚举和转换/转换会更容易。

Answer 2

同时我发现了一些事情，如果其他人感兴趣的话：

• switch 块无法与枚举类一起使用。

• 用户empi提到了上述枚举类示例与Java枚举的相似性。似乎在Java世界中，有一种公认的模式，称为Typesafe Enum；显然，这种模式可以追溯到 Joshua Bloch 的书 Effective Java。

Answer 3

事实上，我在工作中一直在为类似的事情而苦苦挣扎。

它基于 发布的示例作者：John B Jon Skeet 的博客文章“C# 中的增强枚举”< /a>.

我无法在没有很多丑陋的情况下正常工作的是通过派生基本枚举类并添加派生类型的附加静态字段来扩展枚举。

如果您检查该博客中发布的基础知识，您会注意到派生类将共享一组具有严重打字问题的通用值，并且当在两个不同的其他类中派生某个枚举基类时，它们的值集将位于也是同一个集合。

我的意思是，您很难创建 DerivedEnumClass1 变量，并且必须在该变量中存储其枚举集合中的值，该值实际上是 BaseEnumClass1 类型，而无需解决方法。

另一个问题是我们经常使用的 Xml 序列化。我使用两个通用类作为业务对象上枚举变量的数据类型来解决这个问题：一个表示单个枚举值，另一个表示一组枚举值，我用它们来模仿标志枚举行为。它们处理存储在它们所表示的属性中的实际值的 xml 序列化和反序列化。以这种方式重新创建位标志行为所需的只是几个运算符重载。

这些是我遇到的一些主要问题。

总而言之，我对最终结果不太满意，里面有一些难闻的东西，但它现在可以完成工作。

为什么我们的首席架构师决定仍然尝试让它发挥作用，是因为有可能拥有实际的类并通过各种行为（通用的或特定的）扩展它们。到目前为止，我还没有看到很多我无法提供的扩展方法，但我们可能会遇到一些问题。

这里没有任何代码，我周末无法使用它，否则我可以展示我用它去了哪里。虽然不是很漂亮...:o

Answer 4

当我必须与一些遗留代码进行互操作时，我会使用类常量，这些遗留代码需要一些可能被或在一起的模糊位标志值。在这种情况下，枚举可能看起来像

public enum Legacy : ushort
{
  SomeFlag1 = 0x0001,
  SomeFlag2 = 0x0002,
  // etc...
}

那么，由于需要将枚举转换为适当的值，因此 P/Invoke 处的编组可读性较差。

如果它是 const 类变量，则不需要强制转换。

Answer 5

两种方法都是有效的。您应该根据情况进行选择。

我可以补充一点，枚举支持位操作作为标志（甚至有 [Flags] 属性来支持这种语义并从枚举生成漂亮的字符串）。

有一个非常相似的重构，名为用策略模式替换枚举。好吧，就您而言，它还不太完整，因为您的颜色是被动的并且不像策略。但是，为什么不把它看作一个特例呢？

Answer 6

是的，Joshua Bloch 所著的《Effective Java》的原始版本在 Java 1.5 之前发布，并且对 Java 中的枚举提供本机支持，它演示了 Typesafe Enum 模式。不幸的是，该书的最新版本针对的是 Java > 1.5，所以它使用Java枚举代替。

其次，在 Java 中不能从 int 转换为 enum。

Color nonsenseColor = (Color)17; // compile-error

但我不会说其他语言。