因為界面應該是“你可以從課外看到的東西”。添加非公開方法是沒有意義的。

雖然經常被引用的原因是“接口定義公共API”，但我認為這是一種過度簡化。（它也“循環”了循環邏輯。）

• 嵌套接口可以是受保護的或私有的，如果是這種情況，它根本不會定義公共接口。

• 擁有具有訪問修飾符混合的接口并沒有意義; 例如，部分公開，部分限制在與界面相同的包中的其他類。事實上，在某些情況下，這可能是非常有用的，IMO。

實際上，我認為使接口成員隱式公開的推理部分是它使Java變得更簡單：

• 隱式公共接口成員對于程序員來說更容易處理。你有多少次見過代碼訪問修飾符的代碼（類）看似隨意？許多“普通”程序員很難理解如何最好地管理Java抽象邊界¹。將public / protected / package添加到接口會使它們變得更加困難。

• 隱式公共接口成員簡化了語言規范......因此簡化了Java編譯器編寫者以及實現Reflection API的人員的任務。

這種思路使“接口定義公共API”成為語言設計的結果（或特征）......而不是相反。實際上，這兩種思路可能在Java設計者的腦海中并行發展。

^{1 - 當然，頂級程序員對這些事情沒有任何困難，并且可能歡迎更豐富的訪問控制功能。但是，當他們的代碼被移交給其他人維護時會發生什么？}

我不得不說這個問題已經通過在Java 8中引入默認方法而重新打開了。我現在正在開發的項目，類似于接口的基本性質，意味著從實現中抽象出意圖。

在某些情況下，我可以使用“默認保護”方法大幅簡化我的代碼。事實證明，這實際上并不起作用，因為接口仍然堅持Java 7邏輯。由于上述原因，正常受保護的方法沒有任何意義; 但是如果一個默認的公共方法需要一個不太可能改變的低級資源并且可以由受保護的方法提供，那么在我看來，“默認保護”工作不僅可以保持更清晰的代碼，還可以保護未來的用戶免受意外濫用。

（這不幸地改變了我仍然需要使用其他不必要的摘要過度復雜化我的代碼的事實;但我確實打算在Oracle中添加一個功能請求。）