接口中的变量答案

【问题标题】：Variables in Interface接口中的变量
【发布时间】：2010-12-23 22:09:06
【问题描述】：

为什么接口中使用的变量是 PUBLIC STATIC FINAL？为什么要特别“静态”？

【问题讨论】：

不久前我在书中读到，最好为这样的接口创建一个变量 myInterface myVarible = new myInterface();比使用类，因为它更容易维护。怎么会这样。
Why are interface variables static and final by default?的可能重复

【解决方案1】：

接口中声明的字段无论如何只能是一个常量，那为什么还要依赖于你使用哪个实例来访问它呢？

如今，将字段放在接口中通常是一种糟糕的风格。该接口旨在反映实现它的类的功能——这与常量的概念完全正交。使用接口just 来声明一堆常量肯定是一个讨厌的想法。我偶尔会发现让接口类型公开简单实现的常量很有用 - 例如，过滤接口可能具有“ALLOW_ALL”和“ALLOW_NONE”字段。

我想你可以设想实现一个接口的场景确实实际上向你的类添加了一个实例字段 - 但这不仅会破坏封装隐式公开，但也可以通过指定部分实现而不是 API。

【讨论】：

现在静态常量参数作为一个整体很糟糕，用 Enums 替换一堆常量是目前正确的 Java 方式，因为它非常类型安全，可以与开关一起使用并且可以编码为包含多个（有用）将值设置为一个常数，基本上避免重复的幻数。
@Jon Skeet Great.. 但我并没有实际实施！
@Esko：枚举在某些情况下是合适的，但它们肯定不会涵盖每个您需要常量的情况。特别是，枚举仅适用于存在一组固定值的情况。例如，为 UTF-8 和其他有保证的字符集设置字符集“常量”会很好 - 但您不想将其设为枚举。不要仅仅因为你有枚举锤就试图让一切看起来像钉子:)
这主要是因为如果考虑到它们的行为，字符集通常不是静态的，也不是恒定的:) 我非常愿意打赌，如果某些东西作为一个概念确实是恒定的，它可以很容易地被一个枚举替换.
我发现在业务逻辑的情况下，最好将常量粘贴到数据库中并在启动时使用 JPA 加载它们，即在 pojo 中。

【解决方案2】：

因为你不能实例化一个接口。也不能有任何方法体来使用非静态非最终变量。

【讨论】：

【解决方案3】：

为什么不是静态的？

它是一个与接口相关联的常量，而不是它的任何特定实例。

【讨论】：

【解决方案4】：

我猜主要原因是虚拟机/语言的实现细节。

如果接口不允许有非静态变量，则在创建类的过程中不需要为接口分配内存。如果您继承具有相同名称的变量，也不需要特殊的命名/重命名机制。您唯一需要的是一些表，以便在使用接口时调用正确的函数。

简而言之 - 它使语言/VM 维护者的生活更轻松。如果您真的想了解多重继承及其陷阱和陷阱，请阅读 Bertrand Meyer 的 Object Oriented Software Construction（第 2 版）。然后你就会明白为什么接口需要如此简单（并且归档了多重继承所做的大部分事情）。

【讨论】：

【解决方案5】：

接口是定义对象之间交互的契约。

这种交互是由公开的方法定义的，而不是由变量定义的。变量只会描述内部工作，而不是交互。

请注意，变量不应该用于交互。根据封装的OOP原则，让一个类直接访问另一个类的变量是犯罪行为。

常量（例如Math.PI）是唯一可接受的例外。由于常量是唯一一种可以被其他类直接访问而不违反封装原则的变量，所以接口中的所有变量都被视为public static final变量（即常量）

【讨论】：