因?yàn)榻缑鎽?yīng)該是“你可以從課外看到的東西”。添加非公開方法是沒有意義的。

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

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

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

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

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

• 隱式公共接口成員簡化了語言規(guī)范......因此簡化了Java編譯器編寫者以及實(shí)現(xiàn)Reflection API的人員的任務(wù)。

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

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

我不得不說這個(gè)問題已經(jīng)通過在Java 8中引入默認(rèn)方法而重新打開了。我現(xiàn)在正在開發(fā)的項(xiàng)目，類似于接口的基本性質(zhì)，意味著從實(shí)現(xiàn)中抽象出意圖。

在某些情況下，我可以使用“默認(rèn)保護(hù)”方法大幅簡化我的代碼。事實(shí)證明，這實(shí)際上并不起作用，因?yàn)榻涌谌匀粓?jiān)持Java 7邏輯。由于上述原因，正常受保護(hù)的方法沒有任何意義; 但是如果一個(gè)默認(rèn)的公共方法需要一個(gè)不太可能改變的低級資源并且可以由受保護(hù)的方法提供，那么在我看來，“默認(rèn)保護(hù)”工作不僅可以保持更清晰的代碼，還可以保護(hù)未來的用戶免受意外濫用。

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