Java 8 默认方法作为特征：安全吗？

Question

在 Java 8 中使用 默认方法作为特征的穷人版本是否安全？

Some claim it may make pandas sad 如果您只是为了它而使用它们，因为它很酷，但这不是我的意图。人们还经常提醒，引入默认方法是为了支持 API 演变和向后兼容性，这是事实，但这并不会导致将它们用作特征本身是错误或扭曲的。

我想到了the following practical use case：

public interface Loggable {
    default Logger logger() {
        return LoggerFactory.getLogger(this.getClass());
    }
}

或者，定义一个PeriodTrait：

public interface PeriodeTrait {
    Date getStartDate();
    Date getEndDate();
    default isValid(Date atDate) {
        ...
    }
}

诚然，可以使用组合（甚至是辅助类），但它看起来更加冗长和混乱，并且不允许从多态中受益。

那么，使用默认方法作为基本特征是否可以/安全，还是我应该担心不可预见的副作用？

Several questions 上的 SO 与 Java 与 Scala 特征有关；这不是重点。我也不仅仅是征求意见。相反，我正在寻找一个权威的答案或至少是现场洞察力：如果您在公司项目中使用默认方法作为特征，那么它会变成定时炸弹吗？

Answer 1

简短的回答是：安全使用它们是安全的 :)

尖刻的回答：告诉我你所说的特质是什么意思，也许我会给你一个更好的答案:)

说真的，“特质”一词的定义并不明确。许多 Java 开发人员最熟悉 Scala 中表达的特征，但 Scala 远非第一种在名称或效果上具有特征的语言。

例如，在 Scala 中，特征是有状态的（可以有 var 变量）；在堡垒中，他们是纯粹的行为。 Java 的默认方法接口是无状态的；这是否意味着它们不是特征？ （提示：这是一个技巧问题。）

同样，在 Scala 中，特征是通过线性化组合而成的；如果类A 扩展了特征X 和Y，那么X 和Y 的混合顺序决定了X 和Y 之间的冲突如何解决。在 Java 中，这种线性化机制是不存在的（它被拒绝了，部分原因是它太“不像 Java”。）

向接口添加默认方法的最接近的原因是为了支持接口进化，但我们很清楚我们正在超越这一点。无论您认为这是“界面进化++”还是“特征--”都是个人解释的问题。所以，回答你关于安全的问题……只要你坚持机制实际支持的东西，而不是一厢情愿地把它延伸到它不支持的东西，你应该没问题。

一个关键的设计目标是，从接口的客户端的角度来看，默认方法应该与“常规”接口方法没有区别。因此，方法的默认性只对接口的设计者 和实现者 感兴趣。

以下是一些完全符合设计目标的用例：

• 界面演变。在这里，我们正在向现有接口添加一个新方法，就该接口上的现有方法而言，该方法具有合理的默认实现。一个示例是将forEach 方法添加到Collection，其中默认实现是根据iterator() 方法编写的。

• “可选”方法。在这里，接口的设计者说“如果实现者愿意忍受所需要的功能限制，他们就不需要实现这个方法”。例如，Iterator.remove 被赋予一个默认值，它会抛出 UnsupportedOperationException；由于Iterator 的绝大多数实现无论如何都具有这种行为，因此默认使该方法本质上是可选的。 （如果 AbstractCollection 的行为被表达为 Collection 的默认值，我们可能会对可变方法执行相同的操作。）

• 方便的方法。这些是严格为方便起见的方法，同样通常根据类上的非默认方法来实现。第一个示例中的logger() 方法就是一个合理的说明。

• 组合器。这些是基于当前实例实例化接口的新实例的组合方法。例如，方法Predicate.and() 或Comparator.thenComparing() 是组合子的示例。

如果您提供默认实现，您还应该为默认提供一些规范（在 JDK 中，我们为此使用 @implSpec javadoc 标记）以帮助实现者了解他们是否要覆盖该方法。一些默认值，比如便捷方法和组合器，几乎从不被覆盖；其他的，比如可选方法，经常被覆盖。您需要提供足够的规范（不仅仅是文档）来说明默认承诺的作用，以便实现者可以就是否需要覆盖它做出明智的决定。