有人知道com.company.project包结构的实际原因以及为什么它已成为事实上的标准吗?
有人会直接按照这个包结构存储所有文件吗?(顺便说一下,这是从Actionscript的角度来看的)
有人知道com.company.project包结构的实际原因以及为什么它已成为事实上的标准吗?
有人会直接按照这个包结构存储所有文件吗?(顺便说一下,这是从Actionscript的角度来看的)
我经常跳过com.,因为即使是小机构也有多个顶级域名,但在命名空间中拥有所有者的名称肯定是有用的,这样当你开始接入第三方库时,就不会出现命名空间冲突。
想象一下有多少实用程序或日志记录命名空间存在,至少在这里我们有Foo.Logging和Bar.Logging,开发人员可以将一个命名空间别名化。
如果您从您拥有的域名开始,反向表达,那么只有在这一点之后,您才可能与其他按照相同结构进行操作的人产生冲突,因为没有其他人拥有该域名。
它仅在某些平台上使用。
几个原因是:
对于第二点,考虑将有日期记录存储在分层文件结构中的例子。按照 YYYY/MM/DD
的层级结构排列比如按照 DD/MM/YYYY
更明智:在根目录下,您可以看到按年份组织记录的文件夹,接着是按月份组织的,最后是按日组织的。按照其他方式(以天或月为根目录)可能会相当尴尬。
对于域名,通常是 subsub.sub.domain.suffix
,即从小到大。这就是为什么将其转换为分层包名称时,您会得到 suffix.domain.sub.subsub
。
对于第一点,以下摘自《Java语言规范第3版》的部分内容可能会揭示出此包命名约定的一些信息:
开发人员应该采取措施,选择广泛分发的软件包的独特包名称,以避免两个已发布的软件包具有相同的名称。这使得软件包可以轻松自动地安装和编目。本节指定了一种建议的约定,用于生成这样的独特包名称。Java平台的实现鼓励提供自动支持,将一组软件包从本地和非正式的包名称转换为此处描述的独特名称格式。
如果不使用独特的包名称,则可能会在冲突软件包的创建点远处出现包名称冲突。这可能会创建一个对用户或程序员难以解决的情况。当软件包之间存在受限交互的情况时,可以使用ClassLoader
来将具有相同名称的软件包彼此隔离,但不能以对一个天真的程序透明的方式进行。
您可以通过首先拥有(或属于拥有)互联网域名(例如sun.com
)来形成独特的包名称。然后,您按组件反转此名称,以获得com.sun
,并使用此作为您的包名称的前缀,使用您的组织内开发的约定进一步管理包名称。
软件包的名称并不意味着软件包存储在互联网中的位置;例如,名为edu.cmu.cs.bovik.cheese
的软件包不一定可以从Internet地址cmu.edu
或cs.cmu.edu
或bovik.cs.cmu.edu
获取。 生成独特包名称的建议约定仅是一种将软件包命名约定附加到现有广为人知的唯一名称注册表上的方法,而无需创建单独的软件包名称注册表。