Java 中的枚举常量设计为单例，为了并发使用，我通常创建无状态枚举实例并使用方法参数根据需要注入数据。
例子：
目前我正在创建一个具有操作的 REST 服务（使用策略模式的变体实现为枚举）。
public enum Operation {
DO_THIS() {
public Result doSomething(Object theData) {
}
} ,
// Other Operations go here
;
public abstract Result doSomething(Object theData);
}
现在我想收集有关操作被调用的频率以及成功的频率等数据。
我可以在使用枚举实例时将状态保存在外部，但似乎状态应该保存在操作中，因为操作应该包含它自己的状态。
现在我的一般问题是：
有状态的枚举实例（除了并发问题）是一个糟糕的设计吗？
【问题讨论】：
有一个案例可能会证明它是合理的。 枚举可以实现一个接口，通常会考虑特定的用例，它可以让您创建 在运行时/以动态方式公开“一些其他类型的枚举类”，以某种方式命名。
这意味着可以强制枚举“单例”实例实现一些可变的方法签名（作为设置器），当然，您仍然可以使用空代码或 NotSupportedException 隐藏这些。
幸运的是，接口中的 final 方法不允许任何改变状态的可能性。那将是我能想到的唯一“可以理解”的案例。
【讨论】：
有状态的枚举是矛盾的，甚至是反模式！
http://en.wikipedia.org/wiki/Enumeration
枚举是项目的集合，它是该集合中所有项目的完整、有序列表。该术语通常用于数学和理论计算机科学中，指的是集合中所有元素的列表。在统计学中，使用术语分类变量而不是枚举。枚举的精确要求（例如，集合是否必须是有限的，或者列表是否允许包含重复项）取决于数学的分支和工作环境。
枚举具有有限数量的值，这些值应该是常数，它们确实如此。
但是，它们是“一流”Java 对象这一事实完全违背了枚举的意图或精神。
如果需要任何类型的状态，枚举（如前所述）应该在一个方面或有问题的枚举中保持状态，至少应该保持对持有状态的委托类的引用。了解“关注点分离”会有所帮助。
【讨论】：
每次创建可变枚举时，一只小猫就会死去。拯救小猫！
【讨论】：
我完全同意 mparaz 的观点，即它违反了最小惊讶原则。人们期望枚举是常量。
您几乎可以肯定地通过以下方式解决日志记录问题：
DO_THIS() {
public Result doSomething(Object theData) {
MyUtilClass.doSomething(Object theData);
}
}
并将您的日志记录放在其他类中。
但是，如果您无法解决这个问题，最小惊讶原则是一个指导方针；你可以违反它，前提是你给班级的用户足够多的关于正在发生的事情的警告。确保 Enum 声明包含一个 BIG 通知，说明它是可变的，并准确描述可变性是什么。枚举应该仍然有效；它正在对单个实例进行参考比较以测试枚举值。
【讨论】：
任何形式的可变静态都是一种罪过。 （好吧，您可能会使用非泄漏缓存、一些延迟初始化和日志记录形式。）
【讨论】：
是的。 “是”我的意思是“总是”。
如果您想整理关于调用的操作数量的统计信息，请实现一些可观察性。
【讨论】：
这对于枚举来说似乎是一个不好的用途——为什么不使用一个为每个操作创建一个新子类的基本抽象类呢？
【讨论】：
我认为这违反了最小惊讶原则。
人们期望枚举的通用用法与最初设计的一样 - 作为常量或标记，而不是作为具有状态的通用类。
【讨论】：