常量集合是否应该放置在类或接口中？

Question

如果我有一个静态常量集合，我想集中声明它们，以便将它们放入类或接口（Java）中，以便可以在各个项目之间共享它们。

在过去，我看到它们大多放在一个类中，但我开始认为，由于类不会也不应该被实例化，也许它们在接口中会更好，但话又说回来，接口不应该由任何类实现，例如

public class ErrorCodes {
    public static final String ERROR_1 = "-1";
    public static final String ERROR_2 = "-2";
}

或者

public interface ErrorCodes {
    public static final String ERROR_1 = "-1";
    public static final String ERROR_2 = "-2";
}

Answer 1

如果它们具有很强的连接，那么我会将它们放入枚举中：

public enum Error {
  ERROR_1("-1", "foo went wrong"),
  ERROR_2("-2", "bar went wrong");

  private final String id;
  private final String message;

  Error(String id, String message) {
    this.id=id;
    this.message=message;
  }

  public String getId() {
    return id;
  }

  public String getMessage() {
    return message;
  }
}

优点是您可以在代码中实现类型安全，并且可以轻松添加基于 id 的查找（通过构建 HashMap 在构造函数中或通过简单地循环 values()）。

Answer 2

有些人认为常量接口是一种反模式（http://en.wikipedia.org/wiki/Constant_interface< /a>) 。

Answer 3

你应该在课堂上做。

接口是类用户可以访问的可用方法、属性等的描述 - 通过实现接口，您可以保证接口中声明的成员可供用户使用。

另一方面，类是对象的描述，或者（如果您对 OO 原则不是太严格的话……）静态成员的占位符。我个人发现在某些项目中在 Settings 类中存储一堆常量非常有用，因此我不必在整个项目中查找定义。我认为这种方法也是您所追求的。

Answer 4

之前已经讨论过：

您不希望接口中的常量的原因是它会诱使客户端类“实现”该接口（以便访问常量而不用接口名称作为前缀）。不过，您不应该这样做 - 该接口实际上并不是对象功能的接口，而是类外部类型中根深蒂固的编译时便利性。

曾经有一段时间，“常量接口”非常方便，但它一直是“错误的”，而且现在我们有了 import static 语句，甚至懒惰都不能成为使用它的借口。

编辑：尽管我必须同意，对于您问题中提出的场景，枚举更合适。

Answer 5

应考虑使用静态导入此处（用于导入类中定义的常量），或 类型安全枚举。

来自 常量接口

在 Java 早期，将常量​​放入接口中是一种流行的技术，但现在许多人认为这是一种令人厌恶的接口使用方式，因为接口应该处理对象提供的服务，而不是其数据.
同样，类使用的常量通常是实现细节，但将它们放在接口中会将它们提升为类的公共 API。

Answer 6

您应该将它们放在带有私有构造函数的类中。

public class ErrorCodes {
    private ErrorCodes() {} // prevents instantiation
    public static final String ERROR_1 = "-1";
    public static final String ERROR_2 = "-2";

或者

更好的是，使用类型安全的枚举。

Answer 7

我建议结合使用静态导入和常量接口。

如果 Java 接口具有常量字段声明，请记住它们隐式是公共的、静态的和最终的（请参阅 Java 语言规范，Section 9.3。）因此，您始终可以省略这些修饰符，只留下类型，你的常量界面将如下所示：

public interface Constants {
    int AGE = 0x23;
    String NAME = "Andrew";
    boolean IGNORE = true;
}

当然，这应该仅按如下方式使用：

import static Constants.*;

public Whatever {
    public String method() {
        return String.format("%s is %d%c", NAME, AGE, IGNORE ? '?' : '!');
    }
}

我在我的生产代码中使用这种样式没有任何问题，并且感觉它会导致非常整洁，紧凑的常量集合，可以处理枚举无法处理的各种类型的常量，并且可以根据需要进行扩展，这与枚举不同。

另一种可能性（并非所有人都会同意）是在父接口中嵌套接口（甚至枚举类型），从而允许您对常量进行分组。这：

interface MoreConstants {
    int MAGIC = 0xCAFEBABE;
    interface PROPERTIES {
        String NAME = "name";
    }
    enum ERRORS {
        ON_FIRE, ASLEEP, BROKEN, UNSURE;
    }
}

并像这样访问它们，假设静态导入 MoreConstants 接口：

if (!PROPERTIES.NAME.equals(value)) {
    return ERRORS.UNSURE;
}

当然，这些接口永远不应该被实现，我认为这是不好的做法。然而，确保这一点的唯一方法是严格的代码审查......

Answer 8

使用常量接口是一个很好的实践。但您不想实现该接口来使用常量。但使用静态导入如下。

package com.data.job.spark;

public interface Constants {

    /** base api url string literal. */
    public static final String BASE_API_URL = "/api/v1";
        /** message string literal. */
    public static final String MESSAGE = "message";

    /** exception string literal. */
    public static final String EXCEPTION = "exception";
}
=================================
import static com.data.job.spark.Constants.EXCEPTION;

@Component("user360ToScyllaDbLoader")
public class TestConstants implements Serializable{


    private static final long serialVersionUID = 1L;
}

Answer 9

我个人认为，出于与上述相同的原因，应该在类中定义常量。特别是因为一些开发人员通过在想要使用它们的类中实现接口来使用这些常量。当该接口包含大量常量时，您不想再查看该特定类的 javadoc，因为它充斥着对该类可能甚至不使用的常量的描述。

Answer 10

简短的回答是，这取决于。上下文是什么，即用例是什么？

你首先需要做的是问问题：

• 有多少个常数？如果有数百个，那么我会喜欢接口或静态缓存机制，即使接口是反模式。

我在一些代码中看到了数百个常量中的一个常量类，它变得很笨拙。有些常量的名称很相似，因此很难保持它们的正确性和维护性。此外，我会更深入地研究为什么你首先会有这么多常量。但是，我还使用此用例开发了一个自定义报告应用程序，并且他们为此使用了静态缓存，因此，它再次指出了您在用例中试图完成的任务。

• 它们需要通过实现类来共享吗？支持接口，但它又取决于上下文，即常量的数量，并且类都需要共享所有常量吗？
• 它们彼此有关联吗？他们是同一类型吗？枚举指定分配给类型的常量值列表，但如果仅特定类需要它们，则将它们设置为 private static final 并将它们放入该类中。
• 您需要枚举或覆盖它们吗？使用枚举。
• 常量是否将整数表示为字符串代码？使用枚举。

总而言之，我相信这里的正确答案应该基于您尝试使用代码完成的任务。

Answer 11

始终使用接口仅定义合约，使用类定义实现状态（变量和常量）和行为（方法实现）

在接口或类中定义常量

阅读这篇文章，它解释了在类中定义常量与接口中定义常量的优点