英文:
What do Java subpackages do, given that they don't provide a special access relationship?
问题
我在Stack Overflow和其他地方看到过许多帖子声称Java没有子包的概念。经常指出的一点是包和其“子包”之间缺乏任何特殊的访问关系。例如,没有办法将com.example
包中的类或方法暴露给com.example.subpackage
包中的类(反之亦然),而不将其暴露给所有其他包。然而,尽管有这些说法,我发现Java语言规范实际上在第7章 包和模块中定义了“子包”的概念。
包的成员包括在包的编译单元中声明的类和接口类型,以及可以包含自己的编译单元和子包的子包。
因此,在Java中,子包是什么,它有什么作用?
英文:
I have seen a number of posts on Stack Overflow and elsewhere assert that Java does not have the concept of subpackages. One thing often pointed out is the lack of any special access relationship between a package and its "subpackage". For instance, there is no way to expose a class or method in com.example
to classes in com.example.subpackage
(or vice versa) without exposing it to all other packages. However, despite these assertions, I see that the Java Language Specification does in fact define the concept of "subpackage" in Chapter 7. Packages and Modules.
> The members of a package are class and interface types, which are declared in compilation units of the package, and subpackages, which may contain compilation units and subpackages of their own.
What, therefore, is a subpackage in Java, and what does it do?
答案1
得分: 4
子包存在是为了方便地组织代码。它们对类/接口命名施加了限制(一个类的完全限定名不能与子包相同),但除此之外,与两个无关的包没有什么不同。
Java语言规范在第7.1节的包成员中定义了什么是子包。
子包是直接嵌套在另一个包内的任何包。例如,com.example.subpackage
是 com.example
的子包:
包的成员包括其子包、以及包中所有编译单元中声明的顶层类类型和顶层接口类型。
例如,在Java SE平台API中:
- 包
java
有子包awt
、applet
、io
、lang
、net
和util
,但没有编译单元。- 包
java.awt
有一个名为image
的子包,还有一些包含类和接口类型声明的编译单元。
子包在子包和包内的类/接口之间强制实施命名约束。换句话说,在同一个包内,子包和类/接口不能共享相同的名称:
一个包不能包含两个同名的成员,否则会导致编译时错误。
以下是一些例子:
- 因为包
java.awt
有一个子包image
,所以它不能(也不会)包含名为image
的类或接口类型声明。- 如果存在一个名为
mouse
的包,以及该包中的成员类型Button
(可以称为mouse.Button
),那么就不能有任何名为mouse.Button
或mouse.Button.Click
的包。- 如果
com.nighthacks.java.jag
是类型的完全限定名,则不能有任何完全限定名为com.nighthacks.java.jag
或com.nighthacks.java.jag.scrabble
的包。
子包的概念主要是为了组织目的而存在。语言只赋予子包唯一的重要性,即对名称冲突的限制:
包的分层命名结构旨在方便以传统方式组织相关的包,除了禁止一个包有与该包中声明的顶层类型同名的子包之外,它本身没有其他意义。
例如,名为
oliver
的包与另一个名为oliver.twist
的包之间没有特殊的访问关系,名为evelyn.wood
和evelyn.waugh
的包之间也没有特殊的关系。也就是说,包oliver.twist
中的代码对于包oliver
中声明的类型的访问权并不比其他包中的代码更好。
英文:
Subpackages exist to allow code to be conveniently organized. They impose a restriction on class/interface naming (a class cannot have the same fully qualified name as a subpackage), but are otherwise no different than two unrelated packages.
The Java Language Specification defines what subpackages are in section 7.1, Package Members.
A subpackage is any package directly nested within another package. For instance, com.example.subpackage
is a subpackage of com.example
:
> The members of a package are its subpackages and all the top level class types and top level interface types declared in all the compilation units of the package.
>
> For example, in the Java SE Platform API:
>
> * The package java
has subpackages awt
, applet
, io
, lang
, net
, and util
, but no compilation units.
> * The package java.awt
has a subpackage named image
, as well as a number of compilation units containing declarations of class and interface types.
Subpackages enforce naming constraints between subpackages and classes/interfaces within the package. Namely, a subpackage and a class/interface cannot share the same name within the same package:
> A package may not contain two members of the same name, or a compile-time error results.
>
> Here are some examples:
>
> * Because the package java.awt
has a subpackage image
, it cannot (and does not) contain a declaration of a class or interface type named image
.
> * If there is a package named mouse
and a member type Button
in that package (which then might be referred to as mouse.Button
), then there cannot be any package with the fully qualified name mouse.Button
or mouse.Button.Click
.
> * If com.nighthacks.java.jag
is the fully qualified name of a type, then there cannot be any package whose fully qualified name is either com.nighthacks.java.jag
or com.nighthacks.java.jag.scrabble
.
The subpackage concept primarly exists for organizational purposes. The restriction against name conflicts is the only significance afforded to subpackages by the language:
> The hierarchical naming structure for packages is intended to be convenient for organizing related packages in a conventional manner, but has no significance in itself other than the prohibition against a package having a subpackage with the same simple name as a top level type declared in that package.
>
> For example, there is no special access relationship between a package named oliver
and another package named oliver.twist
, or between packages named evelyn.wood
and evelyn.waugh
. That is, the code in a package named oliver.twist
has no better access to the types declared within package oliver
than code in any other package.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论