枚举什么时候不是代码气味？

困境

我已经阅读了很多有关面向对象实践的最佳实践书籍，几乎我读过的每一本书都有一部分内容，他们说枚举是一种代码味道。我认为他们已经错过了解释枚举何时有效的部分。

因此，我正在寻找准则和/或用例，其中枚举不是代码的味道，而实际上是有效的构造。

资料来源：

“根据经验，枚举是代码的味道，应将其重构为多态类。[8]” Seemann，Mark，依赖注入，.Net，2011年，第2页。342

[8] Martin Fowler等人，《重构：改进现有代码的设计》（纽约：Addison-Wesley，1999年），第82页。

语境

我陷入困境的原因是交易API。通过以下方法，他们给了我Tick数据流：

void TickPrice(TickType tickType, double value)

哪里 enum TickType { BuyPrice, BuyQuantity, LastPrice, LastQuantity, ... }

我尝试过围绕该API进行包装，因为打破更改是该API的生活方式。我想跟踪包装器上最后收到的刻度线类型的值，并且通过使用ticktypes字典来做到这一点：

Dictionary<TickType,double> LastValues

在我看来，如果将它们用作键，这似乎是对枚举的正确使用。但是我有第二个想法，因为我确实有一个地方可以根据这个集合做出决定，而且我想不出一种消除消除switch语句的方法，我可以使用一个工厂，但是那个工厂仍然会有一个在某处切换语句。在我看来，我只是在移动东西，但仍然闻起来。

找到枚举的不容易，但是要做到的却不那么容易，如果人们可以分享他们的专业知识，利弊，我将不胜感激。

第二个想法

有些决定和行动是基于这些决定和行动的TickType，我似乎想不出消除枚举/切换语句的方法。我能想到的最干净的解决方案是使用工厂并返回基于的实现TickType。即使那样，我仍然会有一个switch语句，该语句返回接口的实现。

下面列出的是示例类之一，在其中我怀疑自己可能使用的枚举错误：

public class ExecutionSimulator
{
  Dictionary<TickType, double> LastReceived;
  void ProcessTick(TickType tickType, double value)
  {
    //Store Last Received TickType value
    LastReceived[tickType] = value;

    //Perform Order matching only on specific TickTypes
    switch(tickType)
    {
      case BidPrice:
      case BidSize:
        MatchSellOrders();
        break;
      case AskPrice:
      case AskSize:
        MatchBuyOrders();
        break;
    }       
  }
}

枚举用于用例，当您逐字地枚举变量可能采用的每个可能值时。曾经 考虑用例，例如一周中的几天或一年中的月份或硬件寄存器的配置值。既高度稳定又可以用简单值表示的事物。

请记住，如果要制作一个反腐败层，由于要包装的设计，就无法避免在某处使用switch语句，但是如果操作正确，则可以将它限制在一个地方，在其他地方使用多态。

首先，代码气味并不意味着出了什么问题。这意味着可能有问题。enum会因为经常滥用而闻到气味，但这并不意味着您必须避免它们。只是您发现自己打字enum，停下来检查更好的解决方案。

最常发生的特殊情况是，当不同的枚举对应于具有不同行为但具有相同接口的不同类型时。例如，与不同的后端交谈，渲染不同的页面等。使用多态类自然可以更自然地实现这些功能。

在您的情况下，TickType不对应于不同的行为。它们是事件的不同类型或当前状态的不同属性。因此，我认为这是枚举的理想场所。

传输数据枚举时没有代码异味

恕我直言，当传输数据enums用于指示某个字段可以具有受限（很少变化）的一组值时，IMHO 是好的。

我认为它比传输任意strings或更好ints。字符串可能会因拼写和大写字母的不同而引起问题。INTS允许范围内的值传递出来，并没有什么语义（例如，我收到3从您的交易服务，这是什么意思？LastPrice？LastQuantity？别的东西吗？

传输对象和使用类层次结构并不总是可能的。例如，wcf不允许接收端区分已发送的类。

在我的项目中，该服务使用类层次结构来实现操作效果，就在通过DataContract对象进行传输之前，该类层次结构中的对象被复制到union-like对象中，该对象包含一个enum用于指示类型的对象。客户端接收，DataContract并使用的enum值在层次结构中switch创建类的对象，并创建正确类型的对象。

之所以不希望传输类的对象的另一个原因是，对于所传输的对象（例如LastPrice），服务可能需要与客户端完全不同的行为。在这种情况下，不希望发送类及其方法。

switch语句不好吗？

恕我直言，根据调用不同构造函数的单一 switch语句enum不是代码味道。它不一定比其他方法更好或更坏，例如基于类型名的反射；这要看实际情况。

enum到处都有开关是一种代码味道，oop提供了通常更好的替代方法：

• 使用具有已覆盖方法的层次结构中不同类别的对象；即多态性。
• 当层次结构中的类很少更改并且（许多）操作应松散地耦合到层次结构中的类时，请使用访问者模式。

如果使用更复杂的类型该怎么办：

    abstract class TickType
    {
      public abstract string Name {get;}
      public abstract double TickValue {get;}
    }

    class BuyPrice : TickType
    {
      public override string Name { get { return "Buy Price"; } }
      public override double TickValue { get { return 2.35d; } }
    }

    class BuyQuantity : TickType
    {
      public override string Name { get { return "Buy Quantity"; } }
      public override double TickValue { get { return 4.55d; } }
    }
//etcetera

那么您可以从反射加载类型或自己构建类型，但是这里要做的主要事情是您坚持SOLID的Open Close Principle

TL; DR

为了回答这个问题，我现在很难思考时间枚举在某种程度上不是代码的味道。他们有一定的意图要有效地声明（此值存在明显的界限，数量有限的可能性），但是它们固有的封闭性使其在结构上次于标准。

对不起，当我重构大量遗留代码时。/叹气; ^ D

但为什么？

很好的评论，为什么LosTechies就是这种情况：

// calculate the service fee
public double CalculateServiceFeeUsingEnum(Account acct)
{
    double totalFee = 0;
    foreach (var service in acct.ServiceEnums) { 

        switch (service)
        {
            case ServiceTypeEnum.ServiceA:
                totalFee += acct.NumOfUsers * 5;
                break;
            case ServiceTypeEnum.ServiceB:
                totalFee += 10;
                break;
        }
    }
    return totalFee;
} 

这与上面的代码具有所有相同的问题。随着应用程序的变大，拥有类似分支语句的机会将会增加。另外，当您推出更多高级服务时，您将不得不不断修改此代码，这违反了开放式封闭原则。这里也有其他问题。计算服务费的功能不需要知道每个服务的实际金额。那就是需要封装的信息。

除了一点：枚举是一个非常有限的数据结构。如果您没有使用枚举来表示真正的整数，则需要一个类来对抽象进行正确建模。您可以使用Jimmy很棒的Enumeration类使用这些类来将它们也用作标签。

让我们重构它以使用多态行为。我们需要的是抽象，它将允许我们包含计算服务费用所需的行为。

public interface ICalculateServiceFee
{
    double CalculateServiceFee(Account acct);
}

...

现在，我们可以创建接口的具体实现，并将其附加到帐户。

public class Account{
    public int NumOfUsers{get;set;}
    public ICalculateServiceFee[] Services { get; set; }
} 

public class ServiceA : ICalculateServiceFee
{
    double feePerUser = 5; 

    public double CalculateServiceFee(Account acct)
    {
        return acct.NumOfUsers * feePerUser;
    }
} 

public class ServiceB : ICalculateServiceFee
{
    double serviceFee = 10;
    public double CalculateServiceFee(Account acct)
    {
        return serviceFee;
    }
} 

另一个实施案例...

底线是，如果您的行为依赖于枚举值，为什么不使用类似接口或父类的不同实现来确保该值存在呢？就我而言，我正在根据REST状态代码查看不同的错误消息。代替...

private static string _getErrorCKey(int statusCode)
{
    string ret;

    switch (statusCode)
    {
        case StatusCodes.Status403Forbidden:
            ret = "BRANCH_UNAUTHORIZED";
            break;

        case StatusCodes.Status422UnprocessableEntity:
            ret = "BRANCH_NOT_FOUND";
            break;

        default:
            ret = "BRANCH_GENERIC_ERROR";
            break;
    }

    return ret;
}

...也许我应该将状态代码包装在类中。

public interface IAmStatusResult
{
    int StatusResult { get; }    // Pretend an int's okay for now.
    string ErrorKey { get; }
}

然后，每次我需要一种新的IAmStatusResult类型时，我都会对其进行编码...

public class UnauthorizedBranchStatusResult : IAmStatusResult
{
    public int StatusResult => 403;
    public string ErrorKey => "BRANCH_UNAUTHORIZED";
}

...现在，我可以确保早期的代码意识到它具有IAmStatusResult作用域并引用它，entity.ErrorKey而不是更复杂的，死胡同_getErrorCode(403)。

而且，更重要的是，每次添加新类型的返回值时，都无需添加其他代码即可处理它。Whaddya知道，enum和switch可能是代码气味。

利润。

使用枚举是否有代码味道取决于上下文。如果您考虑表达问题，我认为您可以从一些想法中得到答案。因此，您具有不同类型的集合以及对其进行操作的集合，并且需要组织代码。有两个简单的选项：

• 根据操作组织代码。在这种情况下，您可以使用枚举标记不同的类型，并在每个使用标记数据的过程中使用switch语句。
• 根据数据类型组织代码。在这种情况下，您可以用接口替换枚举，并为该枚举的每个元素使用一个类。然后，您可以将每个操作作为每个类中的方法来实现。

哪种解决方案更好？

正如Karl Bielefeldt所指出的，如果您的类型是固定的，并且您希望系统主要通过在这些类型上添加新的操作来增长，那么使用枚举并使用switch语句是一个更好的解决方案：每次您需要一个新的操作时，只需实现一个新过程，而使用类，则必须为每个类添加一个方法。

另一方面，如果您希望有一套相当稳定的操作，但是您认为随着时间的推移将不得不添加更多的数据类型，那么使用面向对象的解决方案会更加方便：由于必须实现新的数据类型，因此您只需继续添加实现同一接口的新类，而如果使用枚举，则必须使用该枚举更新所有过程中的所有switch语句。

如果您无法通过以上两个选项中的任何一个来对问题进行分类，则可以查看更复杂的解决方案（例如，再次参见 上面引述的Wikipedia页面，以进行简短讨论，并提供一些参考资料以供进一步阅读）。

因此，您应该尝试了解应用程序的发展方向，然后选择合适的解决方案。

由于您所参考的书涉及面向对象的范例，因此它们偏爱使用枚举就不足为奇了。但是，面向对象的解决方案并不总是最好的选择。

底线：枚举不一定是代码气味。