Відповідь @Nikita Rybak має хороші моменти, але відсутність деталей, я не можу просто отримати ідею, не глибоко замислюючись, ось що я думав, і тепер я повинен повністю зрозуміти причину.
Чотири модифікатори доступу, припустимо, що 1-й рівень є загальнодоступним, а 4-й рівень - приватним (на основі цієї таблиці послідовно). Перше, що ми повинні знати, чому клас не може бути визначений як приватний на верхньому рівні.
Отже, якщо «приватний клас foo» (визначено приватний член, тобто сам клас є членом) дозволяє, що таке зовнішній (який містить член)? Обсяг файлу? Ні, зовнішній файл безглуздий, оскільки навіть кілька класів в одному файлі будуть скомпільовані в окремі файли класів. Отже, зовнішній пакет . Але модифікатор доступу за замовчуванням 3-го рівня вже означає "приватний пакет ". Тож модифікатор приватного доступу 4-го рівня не буде використовуватися / дозволятись.
Але вкладений приватний клас є допустимим, оскільки прямий зовнішній - це клас, а не пакет, наприклад :
class PrivateNestedMain {
private static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
А що, якщо дозволить "захищений клас foo"? захищеною головною характеристикою є підклас, тому зовнішній (пакет) ПОВИНЕН (через суттєвий обсяг, але все ще необов’язковий) надає стиль підкласу , тобто підпакет, або package A extends package B, але ми не знаємо такого. Отже, захищений не може використовувати повний потенціал (основна сфера дії - для підкласу) у верхньому рівні, який є зовнішнім пакетом (тобто немає такого підпакета), але захищений може використовувати повний потенціал у вкладеному класі, зовнішнім є клас ( тобто може бути підкласом) :
class ProtectedNestedMain {
protected static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
Зверніть увагу, що вищезазначене "не може використовувати весь потенціал", оскільки воно не може охопити підклас лише через те, що жоден зовнішній підклас, тобто засоби, які насправді захищені, не можна дозволити , це просто питання вибору, щоб уникнути дублювання роботи пакета -приватний, якщо зовнішній не підкласний , див. нижче.
Моє заплутування в основному спричинене відомою таблицею за адресою https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html :
Якщо дозволено 1-й рівень (загальнодоступний) та 3-й рівень (приватно-пакувальний), як на землі не дозволяється посередній рівень (захищений)?
підклас державної підтримки, який так легко ввести в оману. Правильно читати цю таблицю
підклас державної підтримки, якщо зовнішній елемент має функцію підкласу.
Те саме введення в оману застосовується до package-private, package-private не підтримує підклас ( N у комірці) не означає, що концепція підкласу застосовується у зовнішньому.
Це означає, що ми повинні ігнорувати стовпець Підклас, якщо функція підкласу недоступна у зовнішній:
Як ми бачимо зараз, і захищений, і пакетно-приватний зараз є однаковим рівнем ( YYN ), більше не виникає плутанини щодо того, чому не дозволяється проміжний рівень. Загалом, Java вибирає лише пакетно-приватний, а не захищений, щоб уникнути плутанини ( це лише питання вибору , але захищена основна характеристика - це підклас, отже пакет-приватний є вищим), і в результаті на верхньому рівні дозволено лише 2 модифікатори доступу:
На верхньому рівні - загальнодоступний або приватно-пакувальний (без явного модифікатора).