我见过这样的例子:
public class MaxSeconds {
public static final int MAX_SECONDS = 25;
}
假设我可以有一个Constants类来包装常量,并将它们声明为静态final。我几乎不知道Java,我想知道这是否是创建常量的最佳方式。
我见过这样的例子:
public class MaxSeconds {
public static final int MAX_SECONDS = 25;
}
假设我可以有一个Constants类来包装常量,并将它们声明为静态final。我几乎不知道Java,我想知道这是否是创建常量的最佳方式。
当前回答
我使用以下方法:
public final class Constants {
public final class File {
public static final int MIN_ROWS = 1;
public static final int MAX_ROWS = 1000;
private File() {}
}
public final class DB {
public static final String name = "oups";
public final class Connection {
public static final String URL = "jdbc:tra-ta-ta";
public static final String USER = "testUser";
public static final String PASSWORD = "testPassword";
private Connection() {}
}
private DB() {}
}
private Constants() {}
}
例如,我使用Constants.DB.Connection.URL来获取常量。 对我来说,它看起来更“面向对象”。
其他回答
我同意大多数人所说的,在处理常量集合时最好使用枚举。然而,如果你在Android上编程,有一个更好的解决方案:IntDef Annotation。
@Retention(SOURCE)
@IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST,NAVIGATION_MODE_TABS})
public @interface NavigationMode {}
public static final int NAVIGATION_MODE_STANDARD = 0;
public static final int NAVIGATION_MODE_LIST = 1;
public static final int NAVIGATION_MODE_TABS = 2;
...
public abstract void setNavigationMode(@NavigationMode int mode);
@NavigationMode
public abstract int getNavigationMode();
IntDef注释在一个简单的方面优于枚举,它占用的空间明显更少,因为它只是一个编译时标记。它不是一个类,也没有自动字符串转换属性。
仅仅为了保存常量而使用接口是一种糟糕的做法(Josh Bloch将其命名为常量接口模式)。以下是乔希的建议:
如果常数与 现有的类或接口 是否应该将它们添加到类中 接口。例如,所有的 盒装的数字基元类, 如Integer和Double,导出 MIN_VALUE和MAX_VALUE常量。如果 这些常数最好看成 枚举类型的成员 应该用enum导出它们吗 类型。否则,您应该导出 带有不可实例化对象的常量 实用程序类。
例子:
// Constant utility class
package com.effectivejava.science;
public class PhysicalConstants {
private PhysicalConstants() { } // Prevents instantiation
public static final double AVOGADROS_NUMBER = 6.02214199e23;
public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
public static final double ELECTRON_MASS = 9.10938188e-31;
}
关于命名约定:
按照惯例,这些字段有名称 由大写字母组成的 用下划线分隔的单词。它是 重要的是,这些字段包含 要么是原始值,要么是引用 到不可变对象。
我同意使用界面不是正确的方法。在Bloch的《Effective Java》中,避免这种模式甚至有自己的项目(#18)。
Bloch反对常量接口模式的一个论点是,常量的使用是一个实现细节,但是实现一个使用它们的接口会在导出的API中暴露该实现细节。
public|private static final TYPE NAME = VALUE;模式是一种声明常数的好方法。就我个人而言,我认为最好避免创建一个单独的类来存放所有的常量,但除了个人偏好和风格之外,我还没有看到不这样做的理由。
如果常量可以很好地建模为枚举,请考虑1.5或更高版本中可用的枚举结构。
如果您使用的是1.5以前的版本,您仍然可以通过使用普通的Java类来实现类型安全枚举。(详见这个网站)。
您可能犯的第一个错误是创建一个全局可访问的类,类名为泛型名称,如Constants。这只会充斥着垃圾,您将无法确定系统的哪个部分使用了这些常量。
相反,常量应该放到“拥有”它们的类中。有一个叫TIMEOUT的常量吗?它应该放到Communications()或Connection()类中。MAX_BAD_LOGINS_PER_HOUR吗?进入User()。诸如此类。
当“常量”可以在运行时定义,但用户不容易更改时,另一种可能的用法是Java .properties文件。你可以把它们打包到你的.jar文件中,并使用Class resourceLoader引用它们。
I use static final to declare constants and go with the ALL_CAPS naming notation. I have seen quite a few real life instances where all constants are bunched together into an interface. A few posts have rightly called that a bad practice, primarily because that's not what an interface is for. An interface should enforce a contract and should not be a place to put unrelated constants in. Putting it together into a class that cannot be instantiated (through a private constructor) too is fine if the constant semantics don't belong to a specific class(es). I always put a constant in the class that it's most related to, because that makes sense and is also easily maintainable.
枚举是表示一组值的好选择,但是如果您要存储强调绝对值的独立常量(例如。TIMEOUT = 100 ms)你可以直接使用静态的final方法。