在接口中受保护

Question

在接口中受保护为什么interface定义中的所有方法都是隐含的public？为什么它不允许protected方法？

Answer 1

因为界面应该是“你可以从课外看到的东西”。添加非公开方法是没有意义的。

Answer 2

虽然经常被引用的原因是“接口定义公共API”，但我认为这是一种过度简化。（它也“循环”了循环逻辑。）

• 嵌套接口可以是受保护的或私有的，如果是这种情况，它根本不会定义公共接口。

• 拥有具有访问修饰符混合的接口并没有意义; 例如，部分公开，部分限制在与界面相同的包中的其他类。事实上，在某些情况下，这可能是非常有用的，IMO。

实际上，我认为使接口成员隐式公开的推理部分是它使Java变得更简单：

• 隐式公共接口成员对于程序员来说更容易处理。你有多少次见过代码访问修饰符的代码（类）看似随意？许多“普通”程序员很难理解如何最好地管理Java抽象边界¹。将public / protected / package添加到接口会使它们变得更加困难。

• 隐式公共接口成员简化了语言规范......因此简化了Java编译器编写者以及实现Reflection API的人员的任务。

这种思路使“接口定义公共API”成为语言设计的结果（或特征）......而不是相反。实际上，这两种思路可能在Java设计者的脑海中并行发展。

---

^{1 - 当然，顶级程序员对这些事情没有任何困难，并且可能欢迎更丰富的访问控制功能。但是，当他们的代码被移交给其他人维护时会发生什么？}

Answer 3

我不得不说这个问题已经通过在Java 8中引入默认方法而重新打开了。我现在正在开发的项目，类似于接口的基本性质，意味着从实现中抽象出意图。

在某些情况下，我可以使用“默认保护”方法大幅简化我的代码。事实证明，这实际上并不起作用，因为接口仍然坚持Java 7逻辑。由于上述原因，正常受保护的方法没有任何意义; 但是如果一个默认的公共方法需要一个不太可能改变的低级资源并且可以由受保护的方法提供，那么在我看来，“默认保护”工作不仅可以保持更清晰的代码，还可以保护未来的用户免受意外滥用。

（这不幸地改变了我仍然需要使用其他不必要的摘要过度复杂化我的代码的事实;但我确实打算在Oracle中添加一个功能请求。）