blocks|key|1994850|text|你的问题很笼统，我敢肯定没有一个正确的答案。但是根据spring*标记来判断，我想您可能是在询问DTO中的枚举，这些枚举是以序列化的形式通过您的系统发送的。如果是这样的话，我建议在DTO中选择String，而在单个应用程序中使用enum是可以的。然后，您将只关心以工厂方式进行反序列化/转换，能够通过日志记录/提供回退或有意义的错误来优雅地处理未知/缺失常量。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1994851|entityMap^0|2O|6|36|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

Your question is pretty generic and I'm pretty sure there is no single right answer. But judging based on spring* tags, I suppose you might be asking about enums in DTOs that being sent over your system in serialized form. If that's the case, I would recommend to choose <code>String</code> in DTO, while inside single app it's ok to use <code>enum</code>. Then you would just care about deserialization/conversion in a factory manner, having ability to handle unknown/missing constant gracefully by logging/providing fallback or meaningful error.

blocks|key|1151847|text|这取决于逐个案例的情况，而你的问题没有太多的背景。但是，我确实建议在许多情况下使用ENUM，包括如果您期望ENUM的列表增加。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1151848|使用它们的一些理由是：|1151849|它创建了一个明确的ENUM元素指南，可以在整个代码中使用。它消除了关于某物的名称或它是什么的不确定性。例如，包含动物列表的ENUM，或“某事”的枚举。|ordered-list-item|1151850|如果您需要更改任何内容，稍后再重构是很容易的。|1151851|我相信还有更多的原因，有时我会发现它就像一张目录。在很多情况下，你可以完全避免它，而且很好，但我认为，如果你是在围栏一般使用它更好。|1151852|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|P|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Q|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|L|$]]

It depends on a case-by-case situation and your question doesn't have much context. However, I do recommend using ENUMs for many cases, including if you expect the list of ENUMs to increase.

Some reasons to use them are:

<ol>
<li>It creates a definite guide of ENUM elements that can be used throughout your code. It eliminates uncertainty over what something is named or what it is. For example ENUM that contains list of animals, or enum of "something".</li>
<li>Its easy to refactor later if you need to change anything.</li>
</ol>

I'm sure there are many more reasons, I find it like a table of contents sometimes. For many cases, you can completely avoid it and be fine but I think its better to use it in general if you're on the fence.

blocks|key|1994901|text|tl;dr|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1994902|如果在编译时知道全部可能的值，则使用enum。|unordered-list-item|offset|length|style|BOLD|1994903|如果在系统使用时(在运行时)可以添加或删除值，则不能使用枚举。改用Set、List或Map。|CODE|1994904|已知于编译时|1994905|当域(所有可能的值的集合)在编译时已知时，枚举是合适的。|1994906|如果你的公司今年提供两种产品(+Poo+&+your+)，那就为这两种元素做点说明吧。|1994907|public+enum+Product+{+POO+,+TOO+}|code-block|syntax|javascript|1994908|明年，你的公司决定通过添加App+&+Laa来增加他们的产品。作为计划部署的一部分，在枚举中再添加两个对象。|1994909|public+enum+Product+{+POO+,+TOO+,+APP+,+LAA+}|1994910|顺便说一句，请注意命名约定。枚举有一个常规的类名(首字母上限)。被自动实例化的对象是常量，所以用大写字母命名.|1994911|另外，请注意，Java中的enum工具非常灵活和强大，比大多数语言中常见的命名a-s+enum方案都要灵活得多。您可以在Java枚举上拥有成员变量、方法和构造函数。例如，您可以添加一个getDisplayName方法，以提供比全大写对象名更适合用户界面的文本，如DayOfWeek::getDisplayName中所示。您可以添加相当多的功能，如ChronoUnit.between。|1994912|在运行时使用Java中的枚举不能做的是添加或删除对象。因此，您需要在编译时知道您的域。但是，在使用一组枚举对象时，可以使用高度优化的EnumSet和EnumMap类。|1994913|在运行时已知|1994914|如果无法在编译时确定域，如果用户可以在运行时添加或删除元素，则使用集合+(如List、Set或Map+)而不是枚举。|1994915|辛格尔顿|1994916|虽然最初不是作为Java中Enum的目的，但enum恰好是实现https://en.wikipedia.org/wiki/Singleton_pattern设计模式的最安全(也是最简单)的方法。|1994917|约书亚·布洛赫博士等人在著名的“有效Java”一书中解释了这一方法。使用枚举解决了单个实例的其他方法存在的多个模糊的技术问题。|1994918|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/DayOfWeek.html#getDisplayName(java.time.format.TextStyle,java.util.Locale))|1|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/temporal/ChronoUnit.html|2|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/EnumSet.html|3|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/EnumMap.html|4|https://en.wikipedia.org/wiki/Java_collections_framework|5|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Enum.html|6|https://en.wikipedia.org/wiki/Singleton_pattern^0|0|G|6|0|O|6|X|3|11|4|16|3|0|0|0|0|0|0|0|0|2K|E|3N|P|4T|I|3N|P|0|4T|I|1|0|1U|7|22|7|1U|7|2|22|7|3|0|0|12|4|17|3|1B|3|X|2|4|0|0|D|4|D|4|5|V|1B|6|0|0^^$0|@$1|2|3|4|5|6|7|20|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|21|8|@$E|22|F|23|G|H]]|9|@]|A|$]]|$1|I|3|J|5|D|7|24|8|@$E|25|F|26|G|H]|$E|27|F|28|G|K]|$E|29|F|2A|G|K]|$E|2B|F|2C|G|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|2D|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|2E|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|2F|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|2G|8|@]|9|@]|A|$U|V]]|$1|W|3|X|5|6|7|2H|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|T|7|2I|8|@]|9|@]|A|$U|V]]|$1|10|3|11|5|6|7|2J|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|2K|8|@$E|2L|F|2M|G|K]|$E|2N|F|2O|G|K]|$E|2P|F|2Q|G|K]]|9|@$E|2R|F|2S|1|2T]|$E|2U|F|2V|1|2W]]|A|$]]|$1|14|3|15|5|6|7|2X|8|@$E|2Y|F|2Z|G|K]|$E|30|F|31|G|K]]|9|@$E|32|F|33|1|34]|$E|35|F|36|1|37]]|A|$]]|$1|16|3|17|5|6|7|38|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|39|8|@$E|3A|F|3B|G|K]|$E|3C|F|3D|G|K]|$E|3E|F|3F|G|K]]|9|@$E|3G|F|3H|1|3I]]|A|$]]|$1|1A|3|1B|5|6|7|3J|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|3K|8|@$E|3L|F|3M|G|K]]|9|@$E|3N|F|3O|1|3P]|$E|3Q|F|3R|1|3S]]|A|$]]|$1|1E|3|1F|5|6|7|3T|8|@]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|3U|8|@]|9|@]|A|$]]]|1H|$1I|$5|1J|1K|1L|A|$1M|1N]]|1O|$5|1J|1K|1L|A|$1M|1P]]|1Q|$5|1J|1K|1L|A|$1M|1R]]|1S|$5|1J|1K|1L|A|$1M|1T]]|1U|$5|1J|1K|1L|A|$1M|1V]]|1W|$5|1J|1K|1L|A|$1M|1X]]|1Y|$5|1J|1K|1L|A|$1M|1Z]]]]

<h1>tl;dr</h1>

<ul>
<li>If the entire set of possible values is known at compile-time, use enum.</li>
<li>If values can be added or dropped while your system is in use (at runtime), then you cannot use an enum. Use a <code>Set</code>, <code>List</code>, or <code>Map</code> instead.</li>
</ul>

<h1>Known at compile-time</h1>

An enum is appropriate when the domain (set of all possible values) is known at compile-time.

If this year your company is offering two products ( Poo &amp; Too ), then make an enum for those two elements.

<pre><code>public enum Product { POO , TOO }
</code></pre>

Next year, your company decides to grow their product offerings by adding App &amp; Laa. As part of a planned deployment, add two more objects to your enum.

<pre><code>public enum Product { POO , TOO , APP , LAA }
</code></pre>

By the way, notice the naming conventions. The enum has a regular class name (initial cap). The objects being automatically instantiated are constants, and so are named in all-uppercase. 

Also, be aware that the enum facility in Java is quite flexible and powerful, much more so than the usual naming-a-number enum scheme seen in most languages. You can have member variables and methods and constructors on a Java enum. For example, you can add a <code>getDisplayName</code> method to provide text more appropriate to a user-interface than the all-caps object name, as seen in <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/DayOfWeek.html#getDisplayName(java.time.format.TextStyle,java.util.Locale)" rel="nofollow noreferrer"><code>DayOfWeek::getDisplayName</code></a>. You can add quite a bit of functionality, such as <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/temporal/ChronoUnit.html" rel="nofollow noreferrer"><code>ChronoUnit.between</code></a>.

What you cannot do at runtime with an enum in Java is add or remove objects. Thus the requirement that you know your domain at compile-time. However, when working with a group of enum objects, you can use the highly-optimized <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/EnumSet.html" rel="nofollow noreferrer"><code>EnumSet</code></a> and <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/EnumMap.html" rel="nofollow noreferrer"><code>EnumMap</code></a> classes.

<h1>Known at runtime</h1>

If you cannot determine the domain at compile-time, if users can add or remove elements at runtime, then use a <a href="https://en.wikipedia.org/wiki/Java_collections_framework" rel="nofollow noreferrer">collection</a> such as a <code>List</code>, <code>Set</code>, or <code>Map</code> rather than an enum.

<hr>

<h1>Singleton</h1>

Though not originally intended as a purpose of <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Enum.html" rel="nofollow noreferrer"><code>Enum</code></a> in Java, an enum happens to be the safest (and simplest) way to implement the <a href="https://en.wikipedia.org/wiki/Singleton_pattern" rel="nofollow noreferrer">Singleton</a> design pattern. 

This approach to a singleton is explained in the famous book Effective Java by Dr. Joshua Bloch, et al. Using an enum solves multiple obscure technical problems with other approaches to a singleton.

It may be very obvious questions, but is it good to use Enum class if you know that the list of values will keep increasing? 

Let's say you define an Event Enum first it contains only [Poo, Too] then as we know we always have some new requirement it becomes [Poo, Too, App, Laa] and that keep changing again and again, 

So what is the best approach in this case?

When to use Enum class in java?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

这可能是非常明显的问题，但如果您知道值的列表将不断增加，那么使用Enum类会好吗？假设您定义了一个事件Enum，首先它只包含Poo，然后我们知道我们总是有一些新的需求，它也变成了Poo，App，Laa，并且不断地变化，那么，在这种情况下，最好的方法是什么？

问何时在java中使用Enum类？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问何时在java中使用Enum类？EN