为什么Java8不允许非公共的默认方法？

让我们举一个例子：

public interface Testerface {

    default public String example() {
        return "Hello";
    }

}

public class Tester implements Testerface {

    @Override
    public String example() {
        return Testerface.super.example() + " world!";
    }


}

public class Internet {

    public static void main(String[] args) {
        System.out.println(new Tester().example());
    }

}

很简单，这将打印

helloworld。但是假设我使用
Testerface 35; example
的返回值做了其他事情，例如初始化一个数据文件并返回一个不应该离开实现类的敏感内部值。为什么Java不允许在默认接口方法上使用访问修饰符？为什么它们不能被保护/私有，并且可能被子类提升（类似于扩展父类的类可以对重写的方法使用更可见的修饰符的方式）

一个常见的解决方案是移动到一个抽象类，但是在我的特定情况下，我有一个枚举接口，所以这不适用于这里。我想这要么是被忽略了，要么是因为接口背后的最初想法是它们是可用方法的“契约”，但我想我需要输入关于这是怎么回事的

我读过“”，其中说明：

默认方法的基本思想是：它是具有默认实现的接口方法，派生类可以提供更具体的实现

在我看来，可视性根本不会破坏这一方面

与链接的问题一样，因为它看起来很难关闭，在这件事上，一个权威性的答案，而不是基于观点的答案，将是值得赞赏的。
正如我们在和中所看到的，扩展接口以定义行为比它最初出现时更微妙。事实证明，每个可能的修饰语都有自己的故事；这不仅仅是盲目模仿类的工作方式的问题。（这至少在事后看来是显而易见的，因为适用于单个继承的OO建模工具不会自动适用于多个继承。）

让我们从一个显而易见的答案开始：接口一直被限制为只有公共成员，虽然我们在Java8中向接口添加了默认方法和静态方法，但这并不意味着我们必须改变一切，使之“更像”类

<> >不同于<代码>同步< /代码>和<代码>最终< /代码>，这将是严重的错误来支持默认方法，弱可访问性，尤其是私有性，是合理的特征。私有接口方法，无论是静态的还是实例的（请注意，这些方法不是默认的，因为它们不参与继承），都是一个非常明智的工具（尽管它们可以很容易地由非公共帮助器类模拟）

我们实际上考虑了在java 8中执行私有接口方法；由于资源和时间的限制，这大部分是从列表底部掉下来的东西。很可能有一天，这个功能会重新出现在待办事项列表上。（更新：Java 9中添加了接口中的私有方法。）

然而，包装和受保护的方法比它们看起来更复杂；多重继承的复杂性和受保护的

真正含义的复杂性将以各种不那么有趣的方式相互作用。所以我不会让你屏住呼吸

---

所以，简单的回答是，私有接口方法是我们可以在8中完成的，但是我们不能做所有可以做的事情，并且仍然可以发布，所以它被删除了，但是可以回来

接口中私有方法的含义是什么？我认为除了“基于意见的答案”之外，不会有任何其他可用方法。为默认方法想要使用但不会泄漏到世界上的内容创建一个带有受保护静态方法的私有类。也就是说，这听起来像是一个糟糕的设计。@njzk2（和pmorken）：你似乎正在遭受想象力的失败。接口中的私有方法可以从接口中的其他方法体（静态或默认）调用，并且与类中的私有方法一样有用。@njzk2我想你迟到了几年：）所有这些问题都在几年前由JSR-335详细讨论过了，例如。简短回答：Java总是有多个继承类型。默认方法添加行为的多重继承。我们仍然没有的是状态的多重继承，这是最棘手的问题的来源（比如钻石）。现在你需要更新你的语言工作模式……接口上缺少私有方法和默认方法不鼓励开发人员公开变体吗？我认为“鼓励”这个词是错误的。它没有使人泄气。我们很想在8中的接口中加入私有方法，但在您拥有的时间/资源中，您可以做的事情是有限的。好消息：接口中的私有方法看起来会使Java 9变得更强大。尽管Java 8/9中的所有这些新特性看起来非常有用和方便，但我认为这有点令人困惑。根据我自己对“接口”的理解，它的定义更接近于“合同”，而不是它现在的样子。我认为在语言中添加一个表示“没有状态的类”的新实体要比增加“接口”实体漂亮得多。我所想到的是类似于“混合”的东西。@egelev没有人会感到惊讶，在做出这一决定之前，人们对此进行了广泛的辩论。结论是，创建一个与接口几乎但不完全相同的新的顶级抽象（mixin、trait，无论什么），将更加混乱和干扰——并且可能也无法满足人们对mixin/trait含义的预先存在的期望。（很容易说“这是不完美的，你应该做点别的”，但你也必须更深入地思考替代方案本身是否真的更糟糕。）