常量的Java，接口或组合类

我有一个关于我的程序设计的问题。我有一个存储公共常量的类A，以便我可以在另一个类中使用这些常量。常量的Java，接口或组合类

public static final String error_code1 = "Fatal Error"; 
public static final String error_code2 = "XXXX"; 
... 
...

组成与界面之间，我不知道哪一个更适合。从我的想法来看，因为我只需要在我的程序中进行价值比较的常量，所以我认为构图是足够的（低耦合）。

但是，你们可以给我一些建议/参数从软件deign的角度来看？（内聚，耦合，维护困难等）

来源

2014-11-21 hades

这可以用Enums完全解决。 – Mirco 2014-11-21 13:17:41

你应该使用枚举的理想，否则去一个接口。 – 2014-11-21 13:20:20

首先，我建议你在这种情况下使用枚举。

public enum ErrorCode { 
    FATAL_ERROR("Fatal Error"), 
    X_ERROR("XXXX"); 

    public final String msg; 
    private ErrorCode(String msg) { 
     this.msg = msg; 
    } 
}

如果这个不适合你出于某种原因，我会去与私人（未使用）构造一个final实用工具类。

无论如何，由于字段是静态的和最终的，我会而不是考虑引用A或实现A来获取常量。

来源

2014-11-21 13:17:44 aioobe

接口不会比具有私有构造函数的最终类更好吗？ – 2014-11-21 13:21:26

这些类型的字段是实现细节而不是类的合同。仅仅因为它“方便”并不意味着这是个好主意。在你知道它之前，有人*实现*接口来简化对常量的访问。 2天后，没有意识到这些字段是静态的人开始传递ErrorConstants类型的对象。 – aioobe 2014-11-21 13:24:52

你说得对。这就说得通了。 – 2014-11-21 13:35:17

向接口添加常量被认为是反模式，因为接口的主要目的是定义行为契约。使用一个枚举或直接访问它们，因为它们是公共的。

来源

2014-11-21 13:22:17 grid

是的我认为接口不应该被用于常量，因为它失去了接口的目的 – hades 2014-11-21 13:40:12

我不会用接口来存储常量具有静态成员进入的接口（和实现该接口）是一个不好的做法甚至还有一个名字吧，常量接口反模式，请参阅[有效的Java] [1]，第17项：

常数接口模式是使用不好的接口。一个类内部使用一些常量是一个实现细节。实现一个常量接口会导致此实现细节泄漏到该类的导出API中。对类的用户来说，类实现一个不变的接口并不重要。事实上，它甚至可能会混淆它们。更糟糕的是，它代表着一种承诺：如果在将来的版本中，类被修改以便它不再需要使用常量，它仍然必须实现接口以确保二进制兼容性。如果一个非终结类实现了一个常量接口，那么它的所有子类的接口中的常量将会使其名称空间受到污染。

我个人会去找枚举，如果需要的话，我甚至可以用它来产生错误代码或添加相关的字段/方法。

来源

2014-11-21 13:23:58 SMA

另一个类中的字符串/ int/...常量有一个问题：它们被复制到使用类的常量池中，之后没有导入到原始类中。如果你改变一个常量的值，那么使用类不会被强制重新编译。

解决方案将使用一个接口，并“实现”该接口;也许丑陋。更好的是使用枚举。

对于开放式的值域一个不会用枚举，但面向对象的方法：

abstract class ParseError extends RuntimeException 
class ExpressionExpectedError extends ParseError 
class DigitsMayNotFollowLeadingZeroError extends ParseError 
..

在Javadoc一个可能会看到ParseError的所有子类。这里类本身形成域值，实例化承载实际的上下文信息。这是更多的面向对象。在对象上调用几个方法比在常量上调用多个方法要好。然而，枚举也可以与分类方法一起使用：boolean errorHandledBySkippingToNextExpr()。

来源

2014-11-21 13:36:42

常量的Java，接口或组合类

回答

相关问题