Java8默认方法为特征：安全吗？

Question

在Java8中使用缺省方法作为穷人版本的traits是一种安全的做法吗？

有人说，如果你只是为了熊猫而使用它们，可能会让熊猫伤心，因为它很酷，但这不是我的本意。人们还经常提醒说，引入缺省方法是为了支持API演进和向后兼容性，这是真的，但这并不使使用它们作为特征本身是错误的或扭曲的。

我脑海中有以下实际用例：

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

或者，定义periodtrait:

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

关于SO的几个问题与Java vs Scala特性有关；这不是重点。我也不仅仅是在征求意见。相反，我在寻找一个权威的答案，或者至少是实地的洞察力：如果你在你的公司项目中使用了默认方法作为特征，那么它是不是变成了一个定时炸弹？

Answer 1

简短的回答是：如果你安全地使用它们，它是安全的：）

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

严肃地说，“特质”一词并没有很好的定义。许多Java开发人员最熟悉用Scala表示的特性，但Scala远远不是第一种具有特性的语言，不管是名义上还是实际上。

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

>

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

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

组合子。这些是组合方法，它们基于当前实例实例化接口的新实例。例如，方法predicate.and()或comparator.thencomparate()是组合符的示例。

如果您提供了一个缺省实现，那么您还应该为缺省提供一些规范（在JDK中，我们为此使用@implspecjavadoc标记），以帮助实现人员理解他们是否要重写方法。一些默认值，如方便方法和组合子，几乎从不被覆盖；其他方法，如可选方法，经常被重写。您需要提供足够的规范（而不仅仅是文档）来说明缺省promise要做什么，这样实现者就可以做出是否需要重写缺省的明智决定。