blocks|key|351103|text|只需使用最终类即可。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351104|如果您希望能够添加其他值，请使用抽象类。|351105|使用接口没有多大意义，接口应该指定一个约定。您只需要声明一些常量值。|351106|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Just use final class.

If you want to be able to add other values use an abstract class.

It doesn't make much sense using an interface, an interface is supposed to specify a contract. You just want to declare some constant values.

blocks|key|3345064|text|对于这些东西，enums不是最好的选择吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3345065|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html^0|7|5|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Aren't <a href="http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html" rel="nofollow noreferrer">enums</a> best choice for these kinds of stuff?

blocks|key|354870|text|使用最后一个类。为简单起见，您可以使用静态导入在另一个类中重用您的值|type|unstyled|depth|inlineStyleRanges|entityRanges|data|354871|public+final+class+MyValues+{
++public+static+final+String+VALUE1+=+"foo";
++public+static+final+String+VALUE2+=+"bar";
}|code-block|syntax|javascript|354872|在另一个类中：|354873|import+static+MyValues.*
//...

if(variable.equals(VALUE1)){
//...
}|354874|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Use a final class.
for simplicity you may then use a static import to reuse your values in another class

<pre><code>public final class MyValues {
 public static final String VALUE1 = "foo";
 public static final String VALUE2 = "bar";
}
</code></pre>

in another class :

<pre><code>import static MyValues.*
//...

if(variable.equals(VALUE1)){
//...
}
</code></pre>

blocks|key|351143|text|我更喜欢的方法是根本不这样做。当Java5引入类型安全枚举时，常量的时代几乎消失了。甚至在此之前，Josh+Bloch就发布了一个(略显冗长的)版本，该版本适用于Java1.4(以及更早的版本)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351144|除非您需要与一些遗留代码进行互操作，否则实际上没有理由再使用命名字符串/整数常量。|351145|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

My preferred method is not to do that at all. The age of constants pretty much died when Java 5 introduced typesafe enums. And even before then Josh Bloch published a (slightly more wordy) version of that, which worked on Java 1.4 (and earlier).

Unless you need interoperability with some legacy code there's really no reason to use named String/integer constants anymore.

blocks|key|349871|text|或4.将它们放在包含使用常量最多的逻辑的类中|type|unstyled|depth|inlineStyleRanges|entityRanges|data|349872|..。对不起，无法抗拒;-)|349873|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Or 4. Put them in the class that contains the logic that uses the constants the most

... sorry, couldn't resist ;-)

blocks|key|3345173|text|您的澄清声明：“我不会使用枚举，我不会枚举任何东西，只是收集一些彼此不相关的常量。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3345174|如果这些常量根本不相关，为什么要把它们收集在一起呢？将每个常量放在与其关系最密切的类中。|3345175|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Your clarification states: "I'm not going to use enums, I am not enumerating anything, just collecting some constants which are not related to each other in any way."

If the constants aren't related to each other at all, why do you want to collect them together? Put each constant in the class which it's most closely related to.

blocks|key|351199|text|正如Joshua+Bloch在Effective+Java中所指出的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351200|351201|接口应该只用于定义类型，|unordered-list-item|351202|抽象类不会阻止实例化(它们可以被子类化，甚至建议它们被设计为子类化)。|351203|351204|如果所有常量都相关(如行星名称)，则可以使用Enum，将常量值放在与它们相关的类中(如果您有权访问它们)，或者使用不可实例化的实用程序类(定义私有默认构造函数)。|351205|class+SomeConstants
{
++++//+Prevents+instanciation+of+myself+and+my+subclasses
++++private+SomeConstants()+{}

++++public+final+static+String+TOTO+=+"toto";
++++public+final+static+Integer+TEN+=+10;
++++//...
}|code-block|syntax|javascript|351206|然后，如前所述，您可以使用静态导入来使用常量。|351207|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|W|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Y|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|Z|8|@]|9|@]|A|$N|O]]|$1|P|3|Q|5|6|7|10|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|S|$]]

As Joshua Bloch notes in Effective Java:

<ul>
<li>Interfaces should only be used to define types,</li>
<li>abstract classes don't prevent instanciability (they can be subclassed, and even suggest that they are designed to be subclassed).</li>
</ul>

You can use an Enum if all your constants are related (like planet names), put the constant values in classes they are related to (if you have access to them), or use a non instanciable utility class (define a private default constructor).

<pre><code>class SomeConstants
{
 // Prevents instanciation of myself and my subclasses
 private SomeConstants() {}

 public final static String TOTO = "toto";
 public final static Integer TEN = 10;
 //...
}
</code></pre>

Then, as already stated, you can use static imports to use your constants.

blocks|key|352351|text|enum%25s正常。有效Java+(第二版)中的一项enum常量枚举了实现任何值的Java关键字interface的标准选项。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|352352|我更喜欢使用Java关键字interface而不是final+class来表示常量。您隐式获取public+static+final。有些人会争辩说，interface允许糟糕的程序员实现它，但无论您做什么，糟糕的程序员都会编写糟糕的代码。|352353|哪一个看起来更好？|352354|public+final+class+SomeStuff+{
+++++private+SomeStuff()+{
+++++++++throw+new+Error();
+++++}
+++++public+static+final+String+SOME_CONST+=+"Some+value+or+another,+I+don't+know.";
}|code-block|syntax|javascript|352355|或者：|352356|public+interface+SomeStuff+{
+++++String+SOME_CONST+=+"Some+value+or+another,+I+don't+know.";
}|352357|entityMap^0|0|4|P|4|1B|9|0|D|9|P|B|1B|J|23|9|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1A|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|1B|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|1C|8|@]|D|@]|E|$]]|$1|Q|3|R|5|L|7|1D|8|@]|D|@]|E|$M|N]]|$1|S|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|T|$]]

<code>enum</code>s are fine. IIRC, one item in effective Java (2nd Ed) has <code>enum</code> constants enumerating standard options implementing a [Java keyword] <code>interface</code> for any value.

My preference is to use a [Java keyword] <code>interface</code> over a <code>final class</code> for constants. You implicitly get the <code>public static final</code>. Some people will argue that an <code>interface</code> allows bad programmers to implement it, but bad programmers are going to write code that sucks no matter what you do.

Which looks better?

<pre><code>public final class SomeStuff {
 private SomeStuff() {
 throw new Error();
 }
 public static final String SOME_CONST = "Some value or another, I don't know.";
}
</code></pre>

Or:

<pre><code>public interface SomeStuff {
 String SOME_CONST = "Some value or another, I don't know.";
}
</code></pre>

blocks|key|349941|text|我的建议(按优先顺序递减)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|349942|1)+do‘t+do+it.在实际类中最相关的地方创建常量。拥有“一袋常量”的类/接口并不是真正遵循面向对象的最佳实践。|349943|我和其他所有人都会时不时地忽略#1。如果你打算这么做，那么：|349944|2)使用私有构造函数+final类这至少可以防止任何人通过扩展/实现它来方便地访问常量来滥用您的“常量包”。(我知道你说过你不会这么做--但这并不意味着在你之后有人不会这么做)|offset|length|style|BOLD|349945|3)+接口这将工作，但不是我的偏好给出了#2中提到的可能的滥用。|349946|一般来说，仅仅因为这些是常量并不意味着您不应该对它们应用普通的面向对象原则。如果只有一个类关心一个常量，那么这个常量应该是私有的，并且在那个类中。如果测试只关心一个常量-它应该在测试类中，而不是在生产代码中。如果一个常量被定义在多个地方(不只是偶然地相同)-重构以消除重复。以此类推--像对待方法一样对待它们。|349947|entityMap^0|0|0|0|B|25|0|0|W|0|0|4B|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@$H|V|I|W|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@$H|Y|I|Z|J|K]]|9|@]|A|$]]|$1|N|3|O|5|6|7|10|8|@$H|11|I|12|J|K]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|Q|$]]

My suggestions (in decreasing order of preference):

1) Don't do it. Create the constants in the actual class where they are most relevant. Having a 'bag of constants' class/interface isn't really following OO best practices.

I, and everyone else, ignore #1 from time to time. If you're going to do that then:

2) final class with private constructor This will at least prevent anyone from abusing your 'bag of constants' by extending/implementing it to get easy access to the constants. (I know you said you wouldn't do this -- but that doesn't mean someone coming along after you won't)

3) interface This will work, but not my preference giving the possible abuse mention in #2.

In general, just because these are constants doesn't mean you shouldn't still apply normal oo principles to them. If no one but one class cares about a constant - it should be private and in that class. If only tests care about a constant - it should be in a test class, not production code. If a constant is defined in multiple places (not just accidentally the same) - refactor to eliminate duplication. And so on - treat them like you would a method.

blocks|key|355012|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355013|私有构造函数的一个缺点是方法的存在性永远不能被测试。|ordered-list-item|355014|枚举的概念很好地应用于特定的域类型，而将它应用于分散的常量看起来不够好|355015|355016|Enum的概念是“枚举是一组紧密相关的项”。|355017|355018|Extend/implement常量接口是一种糟糕的做法，很难考虑扩展一个不可变的常量而不是直接引用它的需求。|355019|如果像SonarSource这样的应用质量工具，有一些规则会迫使开发人员放弃常量接口，这是一件很尴尬的事情，因为许多项目都喜欢常量接口，很少看到在常量接口上发生“扩展”的事情|355020|355021|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|Q|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|R|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|S|7|@]|8|@]|9|$]]|$1|F|3|-4|4|5|6|T|7|@]|8|@]|9|$]]|$1|G|3|H|4|5|6|U|7|@]|8|@]|9|$]]|$1|I|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|J|3|K|4|C|6|W|7|@]|8|@]|9|$]]|$1|L|3|M|4|C|6|X|7|@]|8|@]|9|$]]|$1|N|3|-4|4|5|6|Y|7|@]|8|@]|9|$]]|$1|O|3|-4|4|5|6|Z|7|@]|8|@]|9|$]]]|P|$]]

<ol>
<li>One of the disadvantage of private constructor is the exists of method could never be tested.</li>
<li>Enum by the nature concept good to apply in specific domain type, apply it to decentralized constants looks not good enough</li>
</ol>

The concept of Enum is "Enumerations are sets of closely related items".

<ol start="3">
<li>Extend/implement a constant interface is a bad practice, it is hard to think about requirement to extend a immutable constant instead of referring to it directly.</li>
<li>If apply quality tool like SonarSource, there are rules force developer to drop constant interface, this is a awkward thing as a lot of projects enjoy the constant interface and rarely to see "extend" things happen on constant interfaces</li>
</ol>

blocks|key|3132522|text|对我来说，最好的方法是enum|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3132523|public+enum+SomeApiConstants+{;

++++public+static+final+String+SOME_CONST+=+"SOME_VALUE";

++++//may+be+in+hierarchy
++++public+enum+ApiMapping+{;
++++++++public+static+final+String+VERSION+=+"/version";
++++++++public+static+final+String+VERSION_LIST+=+"/list/{type}";
++++}
}|code-block|syntax|javascript|3132524|优势：|BOLD|3132525|3132526|clean+code|unordered-list-item|3132527|the私有构造函数不需要为defined|3132528|attempt即可实例化，在编译时验证为java:+enum+types+may+not+be+instantiated|3132529|prevents+to+clone和deserialization|3132530|3132531|entityMap^0|B|4|0|0|0|3|0|0|0|A|0|0|K|14|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|13|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|14|8|@$9|15|A|16|B|M]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|17|8|@]|D|@]|E|$]]|$1|O|3|P|5|Q|7|18|8|@$9|19|A|1A|B|M]]|D|@]|E|$]]|$1|R|3|S|5|Q|7|1B|8|@]|D|@]|E|$]]|$1|T|3|U|5|Q|7|1C|8|@$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|V|3|W|5|Q|7|1F|8|@]|D|@]|E|$]]|$1|X|3|-4|5|6|7|1G|8|@]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|1H|8|@]|D|@]|E|$]]]|Z|$]]

The best approach for me, is <code>enum</code>:
<pre class="lang-java prettyprint-override"><code>public enum SomeApiConstants {;

 public static final String SOME_CONST = &quot;SOME_VALUE&quot;;

 //may be in hierarchy
 public enum ApiMapping {;
 public static final String VERSION = &quot;/version&quot;;
 public static final String VERSION_LIST = &quot;/list/{type}&quot;;
 }
}
</code></pre>
Pros:
<ul>
<li>clean code</li>
<li>the private constructor does not need to be defined</li>
<li>attempt to instantiate is validated in compile time as <code>java: enum types may not be instantiated</code></li>
<li>prevents to clone and deserialization</li>
</ul>

Suppose you need to define a class which all it does is hold constants.

<pre><code>public static final String SOME_CONST = "SOME_VALUE";
</code></pre>

What is the preferred way of doing this?

<ol>
<li>Interface</li>
<li>Abstract Class</li>
<li>Final Class</li>
</ol>

Which one should I use and why?

<hr>
Clarifications to some answers:

Enums - I'm not going to use enums, I am not enumerating anything, just collecting some constants which are not related to each other in any way.

Interface - I'm not going to set any class as one that implements the interface. Just want to use the interface to call constants like so: <code>ISomeInterface.SOME_CONST</code>.

How do you define a class of constants in Java?

Java

假设你需要定义一个类，它所做的一切就是保存常量。public static final String SOME_CONST = "SOME_VALUE";执行此操作的首选方法是什么？InterfaceAbstract类最终类我应该使用哪一个?为什么？​对一些答案的澄清：​枚举-我不会使用枚举，我不会枚举任何东西，只是收...

问在Java中如何定义一类常量？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Java中如何定义一类常量？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Java中如何定义一类常量？
EN