为什么要使用com.company.project结构?

8

有人知道com.company.project包结构的实际原因以及为什么它已成为事实上的标准吗?

有人会直接按照这个包结构存储所有文件吗?(顺便说一下,这是从Actionscript的角度来看的)

4个回答

6
防止命名冲突是这种包结构相当实用的原因。如果您正在使用自己拥有的真实域名,而其他人使用相同角色的包名称,冲突的可能性非常小。
特别是在Java世界中,这是“预期行为”。如果您想找到使用的遗留库的文档,但没有人记得它来自哪里,这也有所帮助 ;-)
关于将文件存储在这样的包结构中:在Java世界中,包实际上是文件夹(或.jar文件内的路径),因此:是的,很多人确实以这种方式存储其文件。
这种结构的另一个实用优点是,您始终可以知道某个库是否是内部开发的。

XML命名空间也是一样。它们可以是任意字符串,但大多数情况下是URL,甚至经常指向有用的信息(例如,命名空间所属的XSD文件)。 - musiKk

2

我经常跳过com.,因为即使是小机构也有多个顶级域名,但在命名空间中拥有所有者的名称肯定是有用的,这样当你开始接入第三方库时,就不会出现命名空间冲突。

想象一下有多少实用程序或日志记录命名空间存在,至少在这里我们有Foo.Logging和Bar.Logging,开发人员可以将一个命名空间别名化。


1

如果您从您拥有的域名开始,反向表达,那么只有在这一点之后,您才可能与其他按照相同结构进行操作的人产生冲突,因为没有其他人拥有该域名。

它仅在某些平台上使用。


1

几个原因是:

  • 使用域名使得实现唯一性更容易,而不需要添加一个新的注册表
  • 就层次结构而言,从大到小自然而然

对于第二点,考虑将有日期记录存储在分层文件结构中的例子。按照 YYYY/MM/DD 的层级结构排列比如按照 DD/MM/YYYY 更明智:在根目录下,您可以看到按年份组织记录的文件夹,接着是按月份组织的,最后是按日组织的。按照其他方式(以天或月为根目录)可能会相当尴尬。

对于域名,通常是 subsub.sub.domain.suffix,即从小到大。这就是为什么将其转换为分层包名称时,您会得到 suffix.domain.sub.subsub

对于第一点,以下摘自《Java语言规范第3版》的部分内容可能会揭示出此包命名约定的一些信息:

7.7 独特的包名

开发人员应该采取措施,选择广泛分发的软件包的独特包名称,以避免两个已发布的软件包具有相同的名称。这使得软件包可以轻松自动地安装和编目。本节指定了一种建议的约定,用于生成这样的独特包名称。Java平台的实现鼓励提供自动支持,将一组软件包从本地和非正式的包名称转换为此处描述的独特名称格式。

如果不使用独特的包名称,则可能会在冲突软件包的创建点远处出现包名称冲突。这可能会创建一个对用户或程序员难以解决的情况。当软件包之间存在受限交互的情况时,可以使用ClassLoader来将具有相同名称的软件包彼此隔离,但不能以对一个天真的程序透明的方式进行。

您可以通过首先拥有(或属于拥有)互联网域名(例如sun.com)来形成独特的包名称。然后,您按组件反转此名称,以获得com.sun,并使用此作为您的包名称的前缀,使用您的组织内开发的约定进一步管理包名称。

软件包的名称并不意味着软件包存储在互联网中的位置;例如,名为edu.cmu.cs.bovik.cheese的软件包不一定可以从Internet地址cmu.educs.cmu.edubovik.cs.cmu.edu获取。 生成独特包名称的建议约定仅是一种将软件包命名约定附加到现有广为人知的唯一名称注册表上的方法,而无需创建单独的软件包名称注册表。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接