枚举中的业务逻辑？

Question

在Enums中放入任何类型的业务逻辑是否被认为是一种好习惯？并不是很严格的逻辑，而是更多类似于便捷实用工具的方法。例如：

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;
 }

}

Answer 1

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

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

Answer 2

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

public enum OrderStatus {

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

 public boolean isOpen()
 { 
   return true;
 }
}

Answer 3

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

[如果符合枚举值，我只会考虑使用Enums，即商务逻辑与实例紧密结合。

Answer 4

由于示例中的逻辑与枚举值（的名称）紧密相关，所以我想不出放置它的更好位置。

Answer 5

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

Answer 6

对于上述简单的商务逻辑来说，这是可以的，但是当涉及到扩展枚举这是不可能的时，我遇到了一个问题。例如，我们在枚举中存储了其他数据，后来又想对许多不同枚举的值进行反向映射，这对于标准类而言很容易实现，但对于枚举而言是不可能的（没有代码重复）。标准类可以执行相同的操作（在switch语句中使用除外），并且更加灵活和可靠。如果枚举可能变得更复杂的逻辑，则最好使用类，否则在我看来，将枚举与简单逻辑结合使用就很好了]