2012-01-10 114 views
3

常量这是一个好主意,到组常量里面Constants类容器类,如如何在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,而不是DbConnectionConstants.URL

+0

分组有时有助于提高清晰度。 '公共类常量{ \t私有静态最后类KeyOffsets \t { \t \t公共静态最终诠释QTY = 0; \t \t \t \t // 8字节(长) \t \t公共静态最终诠释PRICE = 8; \t \t \t \t // 8字节(长) \t} \t偏移 公共静态类\t { \t \t公共静态最终诠释动作= 16; \t} }' – 2012-01-10 20:21:54

+0

http://stackoverflow.com/questions/66066/what-is-the-best-way-to-implement-constants-in-java – JustinKSU 2012-01-10 20:41:18

回答

1

使用枚举http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html

每个JVM将只有一个枚举对象

+0

如何存储数据库服务器密码在枚举? – 2012-01-10 20:41:57

+0

INSTANCE; public final PASSWORD =“abcd”; – ligerdave 2012-01-11 02:33:03

+0

即使这会起作用,这是滥用'enum'。此外,你的论点表明,常量字符串不是由JVM实现的,它们是。 – 2012-01-11 14:58:58

8

我一般喜欢把常量在它们所属的类的副本。例如,文件常量可以在FileManager(或类似的东西)中,在那里使用它们。连接常数可以在您的DBUtil类中使用。

想想JDK。它有一个巨大的常量类吗?号(BorderLayout)使用的常量在类BorderLayout中。 JOptionPane(以及)JOptionPane使用的常量为JOptionPane

+0

如果一个常量只能在一个集中的地方使用一次,我同意这种方法。但是,它可能不适用于更复杂的实现。 – JustinKSU 2012-01-10 20:16:55

-3

您也可以使用abstract作为常量类,甚至比私有构造函数更好。如果使用接口,它将在类层次结构之外使用,并且可以简单地使用implements,尽管隐藏了原点(接口名称)。

虽然有一个问题。如果您只为一个常量导入一个类,编译器可能会删除.class中的导入并自行填写常量。如果稍后更改常量的值,则using类将不会自动重新编译,并保持旧值。

+0

常量接口(或抽象类)通常被认为是反模式。已经引入静态导入以便能够在没有反模式的情况下具有相同的优点。你对进口的评论毫无意义。导入仅在编译时使用。它们不在类文件中。无论您是否输入,常量都是内联的。 – 2012-01-10 20:29:02

+0

@JBNizet yes ** interface **是一种反模式,因此_“虽然隐藏起源。”_ On ** imports **:导入的类名通常出现在编译类的常量池中;对于上述情况并非如此。但同意,我会称这是一个编译器特定的错误。 – 2012-01-10 20:41:38

2

优点:

  1. 你得到一个不错的 “路径”,以您的常量。
  2. 如果参与者遵循指导,您可能会得到一个交叉代码常量约定。

缺点:

  1. 有了许多的常量和许多常量的“域”,这个类可能会过于繁琐操作。
  2. 这并不直观。它让我想起了比Java常量更多的Ant属性。
  3. 它可以防止你的代码模块化。假设你想要将你的数据库连接包和文件处理包分离到不同的应用程序可能使用的不同jar。为数据库管理jar提供文件处理常量是多余的。你可以很容易地拥有许多这样的模块。

总之,当你为自己写一些小应用程序时,这可能会很方便。一般来说,这不是一个好的做法。

1

您可以始终在类路径中使用.properties文件,使用foo.bar.baz表示法。这样可以更轻松地更改值而无需重新编译。 Spring框架提供了一些实用程序来帮助实时刷新这些值。

不过,我同意@JB Nizet@yair,随着与恒定的最相关的类保持是一个更好的主意。