在 Java 中实现常量的最佳方式是什么？[关闭]

https://stackoverflow.com/questions/66066

09-06-2019
|

题

我见过这样的例子：

public class MaxSeconds {
   public static final int MAX_SECONDS = 25;
}

并假设我可以有一个 Constants 类来包装常量，将它们声明为静态最终的。我几乎不懂 Java，并且想知道这是否是创建常量的最佳方法。

解决方案

这是完全可以接受的，甚至可能是标准。

(public/private) static final TYPE NAME = VALUE;

在哪里 TYPE 是类型， NAME 是全部大写的名称，下划线表示空格，并且 VALUE 是常数值；

我强烈建议不要将常量放在自己的类或接口中。

作为旁注：声明为final且可变的变量仍然可以更改；但是，该变量永远不能指向不同的对象。

例如：

public static final Point ORIGIN = new Point(0,0);

public static void main(String[] args){

    ORIGIN.x = 3;

}

这是合法的并且 ORIGIN 那么将是 (3, 0) 处的点。

其他提示

我强烈建议不要使用单个常量类。这在当时看来是个好主意，但是当开发人员拒绝记录常量并且类增长到包含超过 500 个常量，而这些常量彼此完全不相关（与应用程序的完全不同方面相关）时，这通常会导致常量文件完全不可读。反而：

如果您可以访问 Java 5+，请使用枚举来定义应用程序区域的特定常量。对于这些常量，应用程序区域的所有部分都应引用枚举，而不是常量值。您可以像声明类一样声明枚举。枚举可能是 Java 5+ 中最有用（并且可以说是唯一）有用的功能。
如果您有仅对特定类或其子类之一有效的常量，请将它们声明为 protected 或 public 并将它们放置在层次结构中的顶层类上。这样，子类可以访问这些常量值（如果其他类通过公共访问它们，这些常量不仅对特定类有效......这意味着使用该常量的外部类可能与包含常量的类）
如果您有一个定义了行为的接口，但返回值或参数值应该是特定的，那么在该接口上定义常量是完全可以接受的，以便其他实现者可以访问它们。但是，避免创建一个接口只是为了保存常量：它可能会变得和仅仅为了保存常量而创建的类一样糟糕。

它是一个 不良做法 使用接口只是为了保存常量（名为 恒定的界面模式 作者：乔什·布洛赫）。以下是乔希的建议：

如果常数与现有类或接口密切相关，则应将它们添加到类或接口中。例如，所有盒装数字原始类，例如整数和double，导出min_value和max_value常数。如果最好将常数视为枚举类型的成员，则应将其导出枚举类型。否则，您应该以无可置查的公用事业类导出常数。

例子：

// 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;
}

关于命名约定：

按照惯例，此类字段的名称由大写字母组成，并由下划线分开。这些字段包含原始值或对不变对象的引用至关重要。

在《Effective Java》（第二版）中，建议您使用枚举而不是静态整数作为常量。

这里有一篇关于 Java 枚举的很好的文章：http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

请注意，在那篇文章的末尾提出的问题是：

那么什么时候应该使用枚举呢？

答案为：

任何时候你需要一组固定的常量

只是避免使用接口：

public interface MyConstants {
    String CONSTANT_ONE = "foo";
}

public class NeddsConstant implements MyConstants {

}

它很诱人，但违反了封装性并模糊了类定义的区别。

我使用以下方法：

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 变得恒定。对我来说，它看起来更“面向对象”。

在单独的类中创建静态最终常量可能会给您带来麻烦。Java 编译器实际上会对此进行优化，并将常量的实际值放入引用它的任何类中。

如果您稍后更改“常量”类，并且不对引用该类的其他类进行硬重新编译，则最终将使用新旧值的组合。

不要将它们视为常量，而应将它们视为配置参数并创建一个类来管理它们。让这些值是非最终的，甚至考虑使用 getter。将来，当您确定其中一些参数实际上应该由用户或管理员配置时，就会容易得多。

您可能犯的第一个错误是创建一个全局可访问的类，并使用通用名称（例如常量）进行调用。这只会充斥着垃圾，并且您将失去弄清楚系统的哪个部分使用这些常量的所有能力。

相反，常量应该进入“拥有”它们的类。你有一个叫做 TIMEOUT 的常量吗？它可能应该进入您的 Communications() 或 Connection() 类。MAX_BAD_LOGINS_PER_HOUR？进入 User()。等等等等。

另一种可能的用途是 Java .properties 文件，此时可以在运行时定义“常量”，但用户不易更改。您可以将它们打包在 .jar 中，并使用类资源加载器引用它们。

这是正确的做法。

一般常数是不是保存在单独的“常量”类中，因为它们不可发现。如果常量与当前类相关，则将它们保留在那里有助于下一个开发人员。

那么枚举呢？

我更喜欢使用吸气剂而不是常量。这些 getter 可能会返回常量值，例如 public int getMaxConnections() {return 10;}, ，但任何需要常数的东西都会通过吸气剂。

一个好处是，如果您的程序超出了常量的范围（您发现它需要可配置），您只需更改 getter 返回常量的方式即可。

另一个好处是，为了修改常量，您不必重新编译使用它的所有内容。当您引用静态最终字段时，该常量的值将被编译为引用它的任何字节码。

我同意使用界面不是正确的方法。避免这种模式甚至在 Bloch 中有自己的项目 (#18) 有效的Java.

Bloch 反对常量接口模式的一个论点是，常量的使用是一个实现细节，但实现一个接口来使用它们会在导出的 API 中公开该实现细节。

这 public|private static final TYPE NAME = VALUE; 模式是声明常量的好方法。就我个人而言，我认为最好避免创建一个单独的类来容纳所有常量，但除了个人喜好和风格之外，我从未见过不这样做的理由。

如果您的常量可以很好地建模为枚举，请考虑枚举 1.5 或更高版本中提供的结构。

如果您使用的是 1.5 之前的版本，您仍然可以通过使用普通的 Java 类来实现类型安全枚举。（看这个网站了解更多信息）。

根据上面的评论，我认为这是一个很好的方法，可以将老式的全局常量类（具有公共静态最终变量）更改为其类似枚举的等效项，如下所示：

public class Constants {

    private Constants() {
        throw new AssertionError();
    }

    public interface ConstantType {}

    public enum StringConstant implements ConstantType {
        DB_HOST("localhost");
        // other String constants come here

        private String value;
        private StringConstant(String value) {
            this.value = value;
        }
        public String value() {
            return value;
        }
    }

    public enum IntConstant implements ConstantType {
        DB_PORT(3128), 
        MAX_PAGE_SIZE(100);
        // other int constants come here

        private int value;
        private IntConstant(int value) {
            this.value = value;
        }
        public int value() {
            return value;
        }
    }

    public enum SimpleConstant implements ConstantType {
        STATE_INIT,
        STATE_START,
        STATE_END;
    }

}

那么我可以将它们引用为：

Constants.StringConstant.DB_HOST

一个好的面向对象设计不需要很多公开可用的常量。大多数常量应该封装在需要它们完成工作的类中。

有一定的意见来回答这个问题。首先，java中的常量通常被声明为public、static和final。原因如下：

public, so that they are accessible from everywhere
static, so that they can be accessed without any instance. Since they are constants it
  makes little sense to duplicate them for every object.
final, since they should not be allowed to change

我绝不会仅仅因为通常期望实现接口而将接口用于 CONSTANTS 访问器/对象。这看起来不是很有趣吗：

String myConstant = IMyInterface.CONSTANTX;

相反，我会根据一些小的权衡在几种不同的方式之间进行选择，因此这取决于您的需要：

1.  Use a regular enum with a default/private constructor. Most people would define 
     constants this way, IMHO.
  - drawback: cannot effectively Javadoc each constant member
  - advantage: var members are implicitly public, static, and final
  - advantage: type-safe
  - provides "a limited constructor" in a special way that only takes args which match
     predefined 'public static final' keys, thus limiting what you can pass to the
     constructor

2.  Use a altered enum WITHOUT a constructor, having all variables defined with 
     prefixed 'public static final' .
  - looks funny just having a floating semi-colon in the code
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you still have to put explicit 'public static final' before each variable
  - drawback: not type-safe
  - no 'limited constructor'

3.  Use a Class with a private constructor:
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you have to put explicit 'public static final' before each variable
  - you have the option of having a constructor to create an instance
     of the class if you want to provide additional functions related
     to your constants 
     (or just keep the constructor private)
  - drawback: not type-safe

4. Using interface:
  - advantage: you can JavaDoc each variable with an explanation
  - advantage: var members are implicitly 'public static final'
  - you are able to define default interface methods if you want to provide additional
     functions related to your constants (only if you implement the interface)
  - drawback: not type-safe

在 Java 中实现常量的最佳方法是什么？

我们真正应该避免的一种方法 :使用接口来定义常量。

专门创建一个接口来声明常量确实是最糟糕的事情：它违背了设计界面的原因：定义方法契约。

即使已经存在一个接口来满足特定需求，在其中声明常量也没有任何意义，因为常量不应该成为 API 和提供给客户端类的契约的一部分。

为了简化，我们大致有 4 种有效的方法.

和 static final String/Integer 场地：

1）使用一个在内部但不仅声明常量的类。
1 变体）创建一个专门用于声明常量的类。

和 Java 5 enum :

2）在相关目的类中声明枚举（因此作为嵌套类）。
2 变体）将枚举创建为独立类（因此在其自己的类文件中定义）。

总而言之：哪种是最好的方法以及在哪里找到常量？

在大多数情况下，枚举方式可能比 static final String/Integer 方式 我个人认为 static final String/Integer 仅当我们有充分的理由不使用枚举时才应使用方法。
关于我们应该在哪里声明常量值， 这个想法是搜索是否存在一个现有的类，它拥有特定且强大的功能内聚性和恒定的值。如果我们找到这样的类，我们应该使用它作为常量持有者. 。否则，该常量不应与任何一个特定类相关联。

static final String/ static final Integer 相对 enum

枚举的使用确实是一种需要认真考虑的方法。
枚举有很大的优势 String 或者 Integer 恒定场。
他们设置了更强的编译约束。如果定义一个以枚举作为参数的方法，则只能传递枚举类中定义的枚举值（或 null）。
使用 String 和 Integer，您可以用任何兼容类型的值替换它们，即使该值不是在中定义的常量，编译也会很好。 static final String/ static final Integer 字段。

例如，下面在类中定义的两个常量为 static final String 字段：

public class MyClass{

   public static final String ONE_CONSTANT = "value";
   public static final String ANOTHER_CONSTANT = "other value";
   . . .
}

这是一个期望将这些常量之一作为参数的方法：

public void process(String constantExpected){
    ...    
}

您可以通过以下方式调用它：

process(MyClass.ONE_CONSTANT);

或者

process(MyClass.ANOTHER_CONSTANT);

但是没有编译约束可以阻止您以这种方式调用它：

process("a not defined constant value");

仅在运行时并且仅当您一次检查传输的值时才会出现错误。

使用枚举，不需要检查，因为客户端只能在枚举参数中传递枚举值。

例如，这里在枚举类中定义了两个值（因此是开箱即用的常量）：

public enum MyEnum {

    ONE_CONSTANT("value"), ANOTHER_CONSTANT(" another value");

    private String value;

    MyEnum(String value) {
       this.value = value;
    }
         ...
}

这里的方法期望将这些枚举值之一作为参数：

public void process(MyEnum myEnum){
    ...    
}

您可以通过以下方式调用它：

process(MyEnum.ONE_CONSTANT);

或者

process(MyEnum.ANOTHER_CONSTANT);

但编译永远不会允许您以这种方式调用它：

process("a not defined constant value");

我们应该在哪里声明常量？

如果您的应用程序包含一个现有类，该类与常量值具有特定且强大的功能内聚性，则 1) 和 2) 显得更直观。
一般来说，如果这些常量是在操作它们的主类中声明的，或者它的名称很自然地猜测我们会在里面找到它，那么它会简化常量的使用。

例如，在 JDK 库中，指数和 pi 常量值在类中声明，该类不仅声明常量声明 (java.lang.Math).

   public final class Math {
          ...
       public static final double E = 2.7182818284590452354;
       public static final double PI = 3.14159265358979323846;
         ...
   }

使用数学函数的客户通常依赖于 Math 班级。因此，他们可能很容易找到常量，并且还可以记住在哪里 E 和 PI 以非常自然的方式定义。

如果您的应用程序不包含与常量值具有非常具体且强大的功能内聚性的现有类，则 1 变体）和 2 变体）方式会显得更直观。
一般来说，如果在一个操作它们的类中声明这些常量，而我们还有 3 或 4 个其他类来操作它们，那么这些常量的使用并不会变得容易，而且这些类中没有一个比其他类更自然地使用它们。主机常量值。
在这里，定义一个自定义类来仅保存常量值是有意义的。
例如在 JDK 库中， java.util.concurrent.TimeUnit enum 没有在特定类中声明，因为实际上并没有一个且只有一个 JDK 特定类看起来是最直观地保存它：

public enum TimeUnit {
    NANOSECONDS {
      .....
    },
    MICROSECONDS {
      .....
    },
    MILLISECONDS {
      .....
    },
    SECONDS {
      .....
    },
      .....
}

许多类声明于 java.util.concurrent 使用它们：BlockingQueue, ArrayBlockingQueue<E>, CompletableFuture, ExecutorService , ...事实上，他们中没有一个人更适合持有枚举。

任何类型的常量都可以通过在类中创建不可变属性（即具有以下属性的成员变量）来声明： final 修饰符）。通常情况下 static 和 public 还提供了修饰符。

public class OfficePrinter {
    public static final String STATE = "Ready";  
}

在许多应用中，常量的值指示从 n 元组中进行的选择（例如枚举）的选择。在我们的示例中，我们可以选择定义一个枚举类型来限制可能的分配值（即改进的 类型安全):

public class OfficePrinter {
    public enum PrinterState { Ready, PCLoadLetter, OutOfToner, Offline };
    public static final PrinterState STATE = PrinterState.Ready;
}

单一的通用常量类不是一个好主意。常量应该与它们在逻辑上最相关的类分组在一起。

我建议您使用方法，而不是使用任何类型的变量（尤其是枚举）。创建一个与变量同名的方法，并让它返回您分配给变量的值。现在删除该变量并将对其的所有引用替换为对您刚刚创建的方法的调用。如果您认为该常量足够通用，不必为了使用它而创建该类的实例，那么可以将该常量方法设置为类方法。

FWIW，以秒为单位的超时值可能应该是一个配置设置（从属性文件中读取或通过 Spring 中的注入读取）而不是常量。

有什么不同

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

public class MyGlobalConstants {
    private MyGlobalConstants () {} // Prevents instantiation
    public static final int TIMEOUT_IN_SECS = 25;
}

并使用MyGlobalConstants.TIMEOUT_IN_SECS 无论何时我们需要这个常数。我认为两者是相同的。

我不会称该类与常量相同（除了大小写）......我至少会有一类“设置”、“值”或“常量”，其中所有常量都将存在。如果我有很多，我会将它们分组为逻辑常量类（UserSettings、AppSettings 等）

更进一步，您可以将全局使用的常量放置在接口中，以便它们可以在系统范围内使用。例如。

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

但随后不要实施它。只需通过完全限定的类名在代码中直接引用它们即可。

对于常量，枚举是更好的选择恕我直言。这是一个例子

公共类我的类{

public enum myEnum {
    Option1("String1", 2), 
    Option2("String2", 2) 
    ;
    String str;
            int i;

            myEnum(String str1, int i1) { this.str = str1 ; this.i1 = i }


}

我这样做的方法之一是创建一个具有常量值的“全局”类，并在需要访问该常量的类中进行静态导入。

static final 是我的偏好，我只会使用 enum 如果该项目确实是可枚举的。

我用 static final 声明常量并使用 ALL_CAPS 命名符号。我见过很多现实生活中的实例，其中所有常量都集中到一个接口中。有一些帖子正确地称这是一种不好的做法，主要是因为这不是界面的用途。接口应该强制执行契约，并且不应该成为放置不相关常量的地方。如果常量语义不属于特定类，那么将其放入无法实例化（通过私有构造函数）的类中也是可以的。我总是在与其最相关的类中放置一个常量，因为这很有意义并且也易于维护。

枚举是表示一系列值的不错选择，但如果您要存储强调绝对值的独立常量（例如TIMEOUT = 100 ms）你可以直接去 static final 方法。

我同意大多数人的说法，在处理常量集合时最好使用枚举。但是，如果您在 Android 中编程，有更好的解决方案： IntDef 注释.

@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 注释以一种简单的方式优于枚举，它占用的空间显着减少，因为它只是一个编译时标记。它不是一个类，也不具有自动字符串转换属性。

这是 坏习惯和非常烦人的练习 在不了解基本的归零原教旨主义的情况下引用约书亚·布洛赫的话。

我还没有读过任何关于约书亚·布洛赫（Joshua Bloch）的书，所以要么

他是一个糟糕的程序员
或者到目前为止我发现引用他的话的人（我猜约书亚是一个男孩的名字）只是使用他的材料作为宗教脚本来证明他们的软件宗教嗜好是正当的。

正如圣经原教旨主义一样，所有圣经律法都可以总结为

全心全意地热爱基本身份
爱你的邻居如同爱你自己

因此类似地，软件工程原教旨主义可以总结为

用你所有的编程能力和头脑致力于从零开始的基础知识
并像为自己一样，致力于让程序员同事取得卓越的成就。

此外，在圣经原教旨主义圈子中，得出了一个强有力且合理的推论

首先爱自己。因为如果你不太爱自己，那么“爱人如己”的概念就没有多大分量，因为“你有多爱自己”是你爱别人的基准线。

同样，如果你不尊重自己作为一名程序员，只是接受某些编程大师的声明和预言，而不质疑基本原理，那么你对 Joshua Bloch（等）的引用和依赖是毫无意义的。因此，你实际上不会尊重你的程序员同事。

软件编程的基本法则

懒惰是优秀程序员的美德
你要让你的编程生活尽可能轻松、懒惰，从而尽可能有效
你要让你的编程的结果和内容尽可能简单、懒惰，因此对于与你一起工作并学习你的编程内容的邻居程序员来说尽可能有效。

接口模式常量是一个坏习惯???

该宗教法令属于什么基本有效和负责任的规划法律？

只需阅读有关接口模式常量的维基百科文章（https://en.wikipedia.org/wiki/Constant_interface），以及它针对接口模式常量提出的愚蠢借口。

如果没有 IDE 怎么办？作为一名软件程序员，谁不会使用 IDE？我们大多数人都是程序员，他们不希望通过避免使用 IDE 来证明自己具有男子气概的审美生存主义。
- 另外，请稍等一下，微功能编程作为一种不需要 IDE 的方法的支持者。等到您阅读我对数据模型标准化的解释。
使用当前作用域内未使用的变量污染命名空间？可能是这个观点的支持者
- 不知道数据模型标准化，也不知道数据模型标准化的必要性
使用接口来强制执行常量是对接口的滥用。这种做法的支持者有一个坏习惯
- 没有看到“常量”必须被视为合同。接口用于强制执行或预测对合同的遵守情况。
将来将接口转换为已实现的类，即使不是不可能，也是很困难的。哈....嗯……???
- 为什么要把编程这种模式作为自己的持续生计呢？IOW，为什么要让自己陷入这种矛盾且糟糕的编程习惯呢？

无论借口是什么，当涉及到根本有效的软件工程时，没有任何有效的借口来取消或普遍阻止接口常量的使用。

制定美国宪法的开国元勋们的初衷和精神状态是什么并不重要。我们可以争论开国元勋的初衷，但我只关心美国宪法的书面陈述。每个美国公民都有责任利用美国宪法中成文的文学原教旨主义，而不是不成文的建国意图。

同样，我也不关心 Java 平台和编程语言的创始人对接口的“原始”意图。我关心的是 Java 规范提供的有效功能，并且我打算充分利用这些功能来帮助我实现负责任的软件编程的基本法则。我不在乎我是否被认为“违反了界面的意图”。我不在乎 Gosling 或 Bloch 某人关于“使用 Java 的正确方法”的说法，除非他们所说的不违反我有效实现基本原则的需要。

基础是数据模型标准化

您的数据模型如何托管或传输并不重要。无论您使用接口、枚举还是其他任何东西、关系型或非 SQL，如果您不了解数据模型规范化的需求和过程。

我们必须首先定义并规范化一组流程的数据模型。当我们拥有一个连贯的数据模型时，只有这样我们才能使用其组件的流程来定义功能行为和流程块应用程序的领域或领域。然后才能定义各个功能流程的API。

即使是 EF Codd 提出的数据标准化方面现在也受到了严峻的挑战和严峻的挑战。例如他关于 1NF 的声明被批评为模棱两可、不一致和过于简单化，他的其他声明也是如此，尤其是在现代数据服务、回购技术和传输出现的情况下。IMO，应该完全放弃 EF Codd 语句，并设计一组新的数学上更合理的语句。

EF Codd 的一个明显缺陷以及其与人类有效理解不一致的原因是他相信人类可感知的多维、可变维度数据可以通过一组零碎的二维映射来有效地感知。

数据标准化的基础知识

EF Codd 未能表达的内容。

在每个相干数据模型中，这些是要实现的数据模型一致性的连续分级顺序。

数据实例的统一性和同一性。
- 设计每个数据组件的粒度，使它们的粒度处于可以唯一地识别和检索组件的每个实例的级别。
- 不存在实例别名。即，不存在任何一种方式可以使一个标识产生一个以上的组件实例。
不存在实例串扰。并不需要使用组件的一个或多个其他实例来帮助识别组件的实例。
数据组件/维度的统一性和同一性。
- 存在组件去锯齿。必须存在一个可以唯一标识组件/维度的定义。这是组件的主要定义；
- 主要定义不会导致暴露不属于预期组件的子维度或成员组件；
独特的组件去混叠方法。组件必须存在且仅存在一个这样的组件去混叠定义。
存在且仅有一个定义接口或契约来标识组件的层次关系中的父组件。
不存在元件串扰。没有必要使用另一个组件的成员来有助于组件的明确标识。
- 在这样的父-子关系中，父的标识定义不能依赖于子的成员组件集合的一部分。父身份的成员组件必须是完整的子身份，而无需引用子项的任何或所有子项。
抢占数据模型的双模态或多模态外观。
- 当一个组件存在两个候选定义时，这是一个明显的迹象，表明存在两种不同的数据模型混合在一起。这意味着数据模型级别或字段级别存在不一致。
- 应用程序领域必须一致地使用一个且仅一个数据模型。
检测并识别成分突变。除非您对大量数据进行了统计成分分析，否则您可能看不到或看不到治疗成分突变的必要性。
- 数据模型的某些组件可能会周期性地或逐渐地发生变化。
- 模式可以是成员轮换或换位轮换。
- 成员轮换突变可能是组件之间子组件的不同交换。或者必须定义全新的组件。
- 转位突变将表现为维度成员突变为属性，反之亦然。
- 每个突变周期必须被识别为不同的数据模式。
对每个突变进行版本化。这样，当可能需要处理数据模型 8 年前的突变时，您可以取出数据模型的先前版本。

在交互服务组件应用程序的领域或网格中，必须有且仅有一个一致的数据模型，或者存在一种数据模型/版本识别自身的方法。

我们还在问是否可以使用接口常量吗？真的？

数据标准化问题比这个平凡的问题更重要。如果你不解决这些问题，那么你认为接口常量造成的混乱相对来说就不算什么了。齐尔奇。

从数据模型规范化中，您可以将组件确定为变量、属性、契约接口常量。

然后，您确定哪些内容涉及值注入、属性配置占位、接口、最终字符串等。

如果您必须以需要找到一个更容易根据接口常量进行指令的组件为借口，则意味着您养成了不实践数据模型规范化的坏习惯。

也许您希望将数据模型编译到 vcs 版本中。您可以提取出可清晰识别的数据模型版本。

接口中定义的值完全保证是不可变的。并且可以分享。当您需要的只是一组常量时，为什么要从另一个类将一组最终字符串加载到您的类中？

那么为什么不发布数据模型合约呢？我的意思是，如果你能够连贯地管理和规范化它，为什么不呢？...

public interface CustomerService {
  public interface Label{
    char AssignmentCharacter = ':';
    public interface Address{
      String Street = "Street";
      String Unit= "Unit/Suite";
      String Municipal = "City";
      String County = "County";
      String Provincial = "State";
      String PostalCode = "Zip"
    }

    public interface Person {
      public interface NameParts{
        String Given = "First/Given name"
        String Auxiliary = "Middle initial"
        String Family = "Last name"
      }
    }
  }
}

现在我可以通过以下方式引用我的应用程序的合同标签

CustomerService.Label.Address.Street
CustomerService.Label.Person.NameParts.Family

这混淆了jar文件的内容？作为一名 Java 程序员，我不关心 jar 的结构。

这给 osgi 驱动的运行时交换带来了复杂性？Osgi是一种极其有效的手段，可以让程序员继续他们的坏习惯。有比 osgi 更好的选择。

或者为什么不是这个？私有常量不会泄漏到已发布的合约中。所有私有常量都应该分组到一个名为“Constants”的私有接口中，因为我不想搜索常量，而且我懒得重复输入“private Final String”。

public class PurchaseRequest {
  private interface Constants{
    String INTERESTINGName = "Interesting Name";
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

也许甚至是这样：

public interface PurchaseOrderConstants {
  public interface Properties{
    default String InterestingName(){
       return something();
    }
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

接口常量唯一值得考虑的问题是接口何时实现。

这不就是接口的“初衷”吗？就像我会关心开国元勋制定美国宪法的“初衷”，而不是最高法院将如何解释美国宪法的书面信件？？？

毕竟，我生活在自由、狂野的土地和勇敢者的家园。勇敢、自由、狂野——使用界面。如果我的程序员同事拒绝使用高效且懒惰的编程方式，我是否有义务按照黄金法则降低我的编程效率以与他们的保持一致？也许我应该这样做，但这不是一个理想的情况。

许可以下： CC-BY-SA 和归因

不隶属于 StackOverflow

在 Java 中实现常量的最佳方式是什么？[关闭]

接口模式常量是一个坏习惯???

基础是数据模型标准化

数据标准化的基础知识

我们还在问是否可以使用接口常量吗？真的 ？

我们还在问是否可以使用接口常量吗？真的？