枚举中的业务逻辑？答案

【问题标题】：Business logic in Enums?枚举中的业务逻辑？
【发布时间】：2011-03-23 09:03:48
【问题描述】：

将任何类型的业务逻辑放在枚举中是否被认为是一种好习惯？不是很强烈的逻辑，但更像是方便实用的方法。例如：

public enum OrderStatus {

 OPEN, OPEN_WITH_RESTRICTIONS, OPEN_TEMPORARY, CLOSED;


 public static boolean isOpenStatus(OrderStatus sts) {
      return sts == OPEN || sts == OPEN_WITH_RESTRICTIONS || sts == OPEN_TEMPORARY;
 }

}

【问题讨论】：

不会 sts != CLOSED 更简单。

标签： java enums business-logic

【解决方案1】：

恕我直言，这使您可以将相关信息放在可能被使用和搜索的位置。枚举没有理由不是具有实际责任的实际类。

如果这允许您编写更简单的代码和SOLID 代码，为什么不呢？

【讨论】：

现在如果我们能在 C#-land 中做到这一点:(
“枚举没有理由不是具有实际责任的实际类。”：在 Java 中，枚举是实际类；）
@Brian - 就是我的意思，它们应该被这样对待（而不是 C 的枚举）
我希望这就是答案。我之前听说 Enums 应该只是用作保持常量并且本质上是愚蠢的对象。

【解决方案2】：

是的，我认为这是个好主意。但是，我认为使用实例方法可以更干净地实现它：

public enum OrderStatus {

 OPEN, OPEN_WITH_RESTRICTIONS, OPEN_TEMPORARY, 
 CLOSED {
   @Override isOpen() { return false; }
 };

 public boolean isOpen()
 { 
   return true;
 }
}

【讨论】：

【解决方案3】：

我经常将枚举用于单例实例。因此它们几乎只包含业务逻辑。作为隐式扩展Enum 的类，它们甚至可以实现接口。

如果枚举值适合枚举值，我只会考虑使用枚举，即业务逻辑与实例紧密耦合。

【讨论】：

+1 用于使用枚举编写单例，更多人应该使用这种方法。
@Tom Hawtin 一般来说，单身人士没有任何问题。它们可以而且使用不当，但这并不意味着它是一种糟糕的设计模式。
单身人士可以像其他任何事情一样被滥用，但如果使用得当，绝对有用。甚至 Josh Bloch 也建议为此目的使用枚举，b/c 那么您不必担心手动单例类的序列化和其他常见遗漏的细节

【解决方案4】：

由于您示例中的逻辑与枚举值的（名称）密切相关，因此我想不出更好的放置位置。

【讨论】：

【解决方案5】：

枚举的主要工作是使用程序员友好的名称强制执行一组特定的值。如果您的业务逻辑可以表示为一组静态值，那么枚举是一个不错的方法。不要忘记，在 Java 中，您可以创建包含多个 one value 的 Enum 类，如果您有一堆相关值，这很有用。

【讨论】：

【解决方案6】：

对于上面的简单业务逻辑来说没问题，但是当涉及到扩展枚举时我遇到了一个问题，这是不可能的。例如，我们在枚举中存储了额外的数据，后来想要获得许多不同枚举值的反向映射，这对于标准类很容易，但对于枚举是不可能的（没有代码重复）。
标准类可以做同样的事情（除了在 switch 语句中使用）并且更加灵活和可靠。如果枚举可能会变得更复杂的逻辑，最好使用类，否则在我看来，使用简单逻辑的枚举是很好的

【讨论】：