在Java中，具有"受保護"修飾符的成員不僅可以由同一個類和子類訪問，還可以由同一個包中的每個人訪問？

我想知道語言設計的原因，而不是實際的應用程序(例如，測試)

+1坦率地說我也想知道為什么。 它總是讓我感到震驚，因為它是Java中最愚蠢的設計決策之一。

@cletus：我想的時間越長，我就得出結論"包私"是一個沒有深思熟慮的想法。 對于"封裝私有"到實際工作并提供任何類型的實際保護，需要在單個編譯單元內編譯包。 人們不應該在以后加強它們。

修飾符在http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html中有詳細描述。從那里我們看到這個數字。

Modifier ? ? ? ?Class ? ? Package Subclass ?World

public ? ? ? ? ?Y ? ? ? ? Y ? ? ? ? Y ? ? ? ? Y

protected ? ? ? Y ? ? ? ? Y ? ? ? ? Y ? ? ? ? N

no modifier ? ? Y ? ? ? ? Y ? ? ? ? N ? ? ? ? N

private ? ? ? ? Y ? ? ? ? N ? ? ? ? N ? ? ? ? N

由此可見設計決策的原因很明顯：它有一個很好的對稱矩陣。

無論如何它會是對稱的......

謝謝你這張桌子。

@邁克爾·邁爾斯：嗯，不，不管怎樣它都不會對稱。它的對稱性是有原因的。

如果在protected - >包交叉處放置N而不是Y，則它仍然是對稱的。只是不那么漂亮。

@MichaelMyers：我不認為Matrix是對稱的。但目前的情況是：所有Y在對角線之上(和之上)以及所有N在下方。

這種設計基于這樣的想法：包裝是適當的單元，由一個內部一致的團隊維護和發布;繼承關系與誰維護和釋放什么時候關系不大。

感謝您的回答。當然實際上并沒有起作用，因為沒有人阻止你在幾個罐子上分發一個包裝 - 并且在幾個團隊中使用它。所以這是另一個沒有充分考慮的好主意。 Java充滿了一些東西。

在Java 1.0中，有第五個訪問修飾符：private protected。這是protected沒有默認訪問權限。顯然它從來沒有真正正常工作，并在1.1中被刪除。因此看起來聲稱protected被定義為總排序的方式似乎是虛假的。 (編輯：看來，在1.1中刪除第五個訪問修飾符的原因中至少有一個原因是缺少總排序干擾了重載選擇規則。)Java 7中的module訪問修飾符有一些設計問題在這方面。

鑒于認為成員的默認訪問修飾符為"包私有"是個好主意，protected應該至少具有這種訪問級別似乎是合理的。對于我的錢，protected根本不會用語言付費。

我從來沒有聽說過那個，但我在1.1中進入Java ...謝謝！

并且由于沒有人阻止您在不同的jar文件中向包中添加更多類，因此"package private"也不是那么私有。原樣：除了私人和公共之外的任何東西或多或少都是對程序員的暗示，但沒有真正的保護。

一個非常晚的問題，但你有一個來源嗎？我現在想更詳細地了解當時失敗的原因和原因。

@PieterDeBie那是來自記憶。 22年前，我將我正在進行的內部項目從1.0升級到1.1。 bugs.sun.com只給我"私有保護"被刪除以簡化規范的其他部分 - 例如，有關覆蓋的規則要求訪問保護是可比較的(即嚴格地比較弱或強。)

@Martin你可以在清單中將罐子標記為"密封"，這可以防止任何添加。當然可以修改jar本身 - 包括類文件。除非您對jar進行簽名，否則您無法將任何類添加到具有不同簽名的相同運行時包中(假設簽名已經過驗證)。此外，來自不同類加載器的任何類都將位于不同的運行時包中。

基本上它與包作為api控制單元的視圖有關(因此建議使用您的域名啟動您的包 - 保證全局唯一性)，因此可見性從私有 - > package-private - > protected - > public 。如果受保護不是增加包私有，而是增加不同類型的可見性，則必須有某種方法在需要時組合兩種類型的可見性。

但是沒有人阻止你在已經退出的包中添加新類。因此，"私有包"和"受保護"只是對程序員的推薦。兩者都沒有為想要/需要調用該方法的惡意/絕望程序員提供任何真正的保護。 - 像C ++中的"protected"至少會強制使用子類 - 但在Java中你甚至不需要這樣做。

鑒于漸進級別的訪問，私有，包，受保護和公共，如果它受到保護然后打包將會不必要地限制，因為這將迫使我允許子類訪問以便授予同一包的其他成員。然而，直觀地說，應該是同一個包中的其他類比"那里"的其他類更值得信賴。所以在包和公共之間受到保護，因為它允許更廣泛的訪問。

我認為基本原因依賴于直覺，即同一個包中的類之間存在基本的"信任"級別;你可以合理地期望他們彼此做正確的事 - 在大多數情況下，包將由一個工程師或團隊負責，所以應該有一致的設計和諧。

這就是理論。但是在實踐中，只有當一個包需要在一個編譯單元中編譯而無法在外部增強時才會出現這種情況。但情況并非如此，因此，在一個苗條的代表類的幫助下，任何"包私有"方法都可以公之于眾。對程序員的暗示，但不是真正的保護。

@martin：只有在沒有密封的情況下發布包，才能解決這個特殊問題。

"密封包裝" - 從來沒有聽說過，但聽起來很有趣。告訴我更多！ (幾句話幫我google細節就夠了)

我自己找到了：docs.oracle.com/javase/tutorial/deployment/jar/sealman.html - 非常有趣。應該默認;-)。

Java確實遵循其設計原則。當您嘗試減少/縮小子類中公共方法的范圍時會發生什么？一個人得到一個錯誤。

Java范圍修飾符級別如下：private

包中的所有類都應該是友好的，因為它們一起工作。要使成員在包中可用，它將在默認范圍內定義。

子類可以駐留在包外部，再次遵循范圍級別：private

請不要將修飾符限制為僅可見性，但繼承，結構也同時工作并將它們添加到圖片中。如果是這樣的話：private

總結

以上是生活随笔為你收集整理的同包类 和 其他类 java_关于继承：为什么Java中的“protected”修饰符允许访问同一个包中的其他类？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。