Ответ @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!");
}
}
}
А что, если разрешить "protected class foo"? Основная характеристика protected - подкласс, поэтому внешний (пакет) ДОЛЖЕН (из-за расширенной области видимости, но все же он необязателен) предоставлять стиль подкласса , то есть подпакета, или package A extends package B, но мы этого не знаем. Таким образом, защищенный не может использовать весь потенциал (основная область - это подкласс) на верхнем уровне, внешний вид которого является пакетом (т.е. нет такой вещи подпакета), но защищенный может использовать весь потенциал во вложенном классе, внешний - это класс ( т.е. может быть подклассом) :
class ProtectedNestedMain {
protected static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
Обратите внимание, что вышеупомянутый «не может использовать весь потенциал» из-за того, что он не может достичь всего подкласса просто потому, что нет внешнего подкласса, это означает, что фактически защищенный может быть разрешен , это просто вопрос выбора, чтобы избежать дублирования работы пакета -private, если внешний не подклассифицируется , см. ниже.
Мое замешательство в основном вызвано известной таблицей на https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html :
Если 1-й уровень (общедоступный) и 3-й уровень (частный пакет) разрешены, как вообще не разрешен промежуточный 2-й уровень (защищенный)?
подкласс общественной поддержки, который легко ввести в заблуждение. Правильный способ чтения этой таблицы:
подкласс публичной поддержки, если внешний имеет функцию подкласса.
То же заблуждение применимо к package-private, package-private не поддерживает подкласс ( N в ячейке) не означает, что концепция подкласса применяется во внешнем.
Это означает , что мы должны игнорировать Подкласс столбец , если функция подкласса не доступна в наружном:
Как мы теперь видим, и protected, и package-private теперь имеют один и тот же уровень ( YYN ), больше нет путаницы в том, почему промежуточный уровень не разрешен. В целом, Java выбирает только частный пакет вместо защищенного, чтобы избежать путаницы ( это просто вопрос выбора , но защищенная основная характеристика - подкласс, поэтому частный пакет лучше), и в результате на верхнем уровне разрешены только 2 модификатора доступа:
На верхнем уровне - общедоступный или частный для пакета (без явного модификатора).