Этот ответ показывает модификаторы видимости Java и их значение:
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
Мой вопрос: почему разрешающая видимость для всех подклассов подразумевает, что вы должны показывать видимость всем другим классам в вашем пакете? Другими словами, почему создатели Java сделали это так, в отличие от:
Modifier | Class | Subclass | Package | World
————————————+———————+—————————-+——————————+———————
public | y | y | y | y
————————————+———————+—————————+——————————+———————
no modifier | y | y | y | n
————————————+———————+—————————+——————————+———————
protected | y | y | n | n
————————————+———————+—————————+——————————+———————
private | y | n | n | n
Пакет якобы написан и поддерживается той же командой; это нормально иметь более свободный контроль доступа в пакете, предполагая, что программист имеет глубокое знание всего кода.
Подкласс часто записывается кем-то другим; более строгое ограничение на API лучше.
Потому что наоборот, как вы предлагаете, не имеет смысла на практике (что я допускаю, это не так очевидно).
Предположим, что у вас есть пакет, содержащий базовый класс, предназначенный для расширения клиентом (сторонний, другой команды и т.д.), а также другие классы, взаимодействующие с базовым классом (в том же пакете). Это довольно распространенный случай.
Теперь ваш базовый класс может содержать элементы/методы, предназначенные только для использования кодом, поставляемым в пакете, но который должен быть недоступен для клиента, расширяющего класс.
Это просто с модификатором private (по умолчанию) пакета, как сейчас, но было бы невозможно, если бы вы переключили силу. Вы потеряете способность скрывать вещи от своих дочерних классов, все еще делая их доступными для своих компаньонов в пакете.