Java 中带有静态字段的接口，用于共享“常量”

Given the advantage of hindsight, we can see that Java is broken in many ways. One major failing of Java is the restriction of interfaces to abstract methods and static final fields. Newer, more sophisticated OO languages like Scala subsume interfaces by traits which can (and typically do) include concrete methods, which may have arity zero (constants!). For an exposition on traits as units of composable behavior, see http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf. For a short description of how traits in Scala compare with interfaces in Java, see http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-5. In the context of teaching OO design, simplistic rules like asserting that interfaces should never include static fields are silly. Many traits naturally include constants and these constants are appropriately part of the public "interface" supported by the trait. In writing Java code, there is no clean, elegant way to represent traits, but using static final fields within interfaces is often part of a good workaround.

我不会假装自己是对的，但让我们看看这个小例子:

public interface CarConstants {


static final String ENGINE = "mechanical";
static final String WHEEL  = "round";
// ...


}


public interface ToyotaCar extends CarConstants //, ICar, ... {
void produce();
}


public interface FordCar extends CarConstants //, ICar, ... {
void produce();
}


// and this is implementation #1
public class CamryCar implements ToyotaCar {


public void produce() {
System.out.println("the engine is " + ENGINE );
System.out.println("the wheel is " + WHEEL);
}
}


// and this is implementation #2
public class MustangCar implements FordCar {


public void produce() {
System.out.println("the engine is " + ENGINE );
System.out.println("the wheel is " + WHEEL);
}
}

ToyotaCar doesnt know anything about FordCar, and FordCar doesnt know about ToyotaCar. principle CarConstants should be changed, but...

Constants should not be changed, because the wheel is round and egine is mechanical, but... 在未来，丰田的研究工程师发明了电子发动机和扁平车轮! 让我们看看我们的新界面

public interface InnovativeCarConstants {


static final String ENGINE = "electronic";
static final String WHEEL  = "flat";
// ...
}

and now we can change our abstraction:

public interface ToyotaCar extends CarConstants

到

public interface ToyotaCar extends InnovativeCarConstants

现在，如果我们需要改变核心价值，如果引擎或车轮，我们可以改变丰田汽车接口的抽象层，不要触及实施

Its NOT SAFE, I know, 但我还是想知道你有没有想过

根据 JVM 规范，接口中的字段和方法只能包含 Public、 Static、 Final 和 Abtic.从 JavaVM 内部引用

默认情况下，接口中的所有方法都是抽象的，即使你没有明确地提到它。

Interfaces are meant to give only specification. It can not contain any implementations. So To avoid implementing classes to change the specification, it is made final. Since Interface cannot be instantiated, they are made static to access the field using interface name.

我没有足够的声誉来评论 Pleerock，因此我必须创造一个答案。对此我很抱歉，但是他在这方面付出了很大的努力，我想回答他。

Pleerock，您创建了一个完美的示例来说明为什么这些常量应该独立于接口并独立于继承。对于应用程序的客户端来说，在这些汽车实现之间存在技术差异并不重要。对客户来说是一样的，只是车而已。因此，客户端希望从这个角度看待它们，这是一个类似 I _ Somecar 的接口。在整个应用程序将客户端只使用一个视角，而不是每个不同的汽车品牌的不同之处。

如果一个客户想要在购买之前比较汽车，他可以有这样一个方法:

public List<Decision> compareCars(List<I_Somecar> pCars);

接口是关于行为的契约，从一个角度显示不同的对象。你设计它的方式，将每一个汽车品牌都有自己的传承路线。虽然它在现实中是相当正确的，因为汽车可以是不同的，它可以像比较完全不同类型的对象，最后有不同的汽车之间的选择。这就是所有品牌必须共享的界面的视角。常量的选择不应该使这一点成为不可能。请考虑一下 Zarkonnen 的答案。

在 Java 中有很多人讨厌这种模式。但是，静态常量的接口有时确实有值。你必须基本符合以下条件:

1. 这些概念是几个 类

2. 它们的值可能在以后的版本中更改。

3. 所有实现使用相同的值是至关重要的。

例如，假设您正在编写一种假设的查询语言的扩展。在这个扩展中，您将使用一些索引支持的新操作来扩展语言语法。例如。您将拥有一个支持地理空间查询的 R-Tree。

所以你用静态常量写一个公共接口:

public interface SyntaxExtensions {
// query type
String NEAR_TO_QUERY = "nearTo";


// params for query
String POINT = "coordinate";
String DISTANCE_KM = "distanceInKm";
}

Now later, a new developer thinks he needs to build a better index, so he comes and builds an R* implementation. By implementing this interface in his new tree he guarantees that the different indexes will have identical syntax in the query language. Moreover, if you later decided that "nearTo" was a confusing name, you could change it to "withinDistanceInKm", and know that the new syntax would be respected by all your index implementations.

PS: The inspiration for this example is drawn from the Neo4j spatial code.