为什么包可见性优先于子类可见性？

Question

This answer显示了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

Answer 1

据说一个包由同一个团队编写和维护;假设程序员对所有代码都有深入的了解，那么在程序包中拥有更宽松的访问控制是可以的。

子类通常由其他人编写;对API的更严格限制更好。

Answer 2

因为你提出的其他方式并不在实践中有意义（我承认这并不是那么明显）。

假设您有一个包，其中包含一个用于客户端扩展的基类（第三方，其他团队等），以及与基类交互的其他类（在同一个包中）。这是一个很常见的情况。

现在，您的基类可能包含仅 的成员/方法，供程序包中提供的代码使用，但扩展该类的客户端无法访问这些成员/方法。

这就像现在的包私有（默认）修饰符一样简单，但是如果你改变了力量，它将不可能。您将失去隐藏子类中的内容的能力，同时仍然可以将其提供给包中的同伴。