Question

免责声明。我不确定标题是否是最好的。我想不出一个不长的英里。请随时提出改进建议。

当程序员设计一组状态时，应用枚举是很自然的。在例如平日，很明显，传统上接受和直截了当。但是，有时候，我们还需要将状态的原因设置为例如任务管理。我们的州可以如下：

enum Status { New, Active, Inactive }

但仍需要状态，状态或状态原因。通常，我会添加一堆新的枚举，如下所示：

enum StatusOfNew { UnseenYet, RefusedToEvenLookAtAndOrQuitTheJob }
enum StatusOfActive { Assigned, Commenced, BeingTested }
enum StatusOfInactive { Done, Trashed, GivenUpOnBecausePeopleKeepQuittingTheJob }

另一种方法是按以下方式列出所有组合的长列表。

enum Status
{ 
  New_UnseenYet, New_RefusedToEvenLookAtAndOrQuitTheJob,
  Active_Assigned, Active_Commenced, Active_BeingTested,
  Inactive_Done, Inactive_Trashed, Inactive_GivenUpOnBecausePeopleKeepQuittingTheJob
}

然后，我们有了优雅的方法，每个州都有自己的类型，有一个共同的超类和特定的阶段/原因。

class New : Status
{
  enum Reason
  {
    UnseenYet,
    RefusedToEvenLookAtAndOrQuitTheJob
  }
}

考虑到实施的复杂性，维护成本和稳健性的增益之间的关系，我可以互相支付。但是，我想知道是否还有其他需要考虑的方法，要应用的语法或能够解决问题的方法。

主要是，作为一名MS猴子，我想在C＃中看到特定于语言的解决方案。然而，作为一个好奇和开放的生物，我也欢迎来自其他语言的建议。我试图向程序员提出这个问题，但显然，我的问题太愚蠢了，网站告诉我要躲避（没有亵渎意图，错字是故意的，我喜欢鸭子）。

Answer 1

保持简单。这实际上是州和原因。但是你的代码如何得到应该驱动你的设计。

如果您希望两者都具有状态模型，那么您可能需要嵌套枚举。否则，类或类/枚举配置更有意义。

目标是拥有可读，可维护的代码。枚举是为了安全和可读性。所以这个决定是上下文中的恰当之处。

也就是说，没有自上而下自然更好。您的所有方法都适用于正确的上下文。

枚举中是否有枚举的一般方法？

1 个答案: