Project management 为什么使用com.company.project结构？

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

---

是否有人将所有内容都存储在直接反映此包结构的文件夹结构中？（顺便说一句，这是从Actionscript的角度来看的）

如果你从你拥有的域名开始，向后表达，那么只有在这一点之后，你才能与遵循相同结构的任何人发生冲突，因为没有其他人拥有该域名

---

它只在某些平台上使用。

防止名称冲突是这样的包结构的一个相当实际的原因。如果您使用的是您自己的真实域名，而其他所有人都以相同的角色使用他们的包名，那么发生冲突的可能性很小

特别是在Java世界中，这是“预期行为”。如果您想找到您正在使用的遗留库的文档，而没有人能够记住它的来源，那么它也会有所帮助；-）

关于在这样的包结构中存储文件：在Java世界中，包实际上是文件夹（或.jar文件中的路径），因此：是的，很多人确实以这种方式存储文件

---

这种结构的另一个实际优势是，您总是知道某些库是否是内部开发的。

我经常跳过com。因为即使是小的组织也有几个TLD，但在名称空间中包含所有者的名称肯定很有用，所以当您开始使用第三方库时，不会出现名称空间冲突

试想一下会有多少实用程序或日志名称空间，这里至少有Foo.Logging和Bar.Logging，开发人员可以将一个名称空间别名为：）

几个原因是：

• 使用域名可以更容易地实现唯一性，而无需添加新的注册表
• 就层次结构而言，从大调到小调是自然的

第二点，考虑在分层文件结构中存储日期记录的例子。将其分层排列为

yyyyy/MM/DD

比说

DD/MM/yyyyy

更明智：在根级别，您可以看到按年份组织记录的文件夹，然后在下一级别按月份组织记录，最后是按天组织记录。用另一种方式（在根级别上用几天或几个月的时间）可能会相当尴尬

对于域名，它通常是

subsub.sub.domain.suffix

，即从次要到主要。这就是为什么在将其转换为分层包名称时，会得到后缀.domain.sub.sub

关于第一点，这里是Java语言规范第3版的一个摘录，它可能会对这个包命名约定有所启发：

开发人员应该采取措施，为广泛分发的包选择唯一的包名，以避免两个已发布包具有相同名称的可能性。这使得软件包可以轻松、自动地安装和编目。本节指定生成此类唯一包名称的建议约定。鼓励Java平台的实现自动支持将一组包从本地和临时包名转换为此处描述的唯一名称格式

如果未使用唯一的包名，则在远离冲突包的创建点时，可能会出现包名冲突。这可能会造成用户或程序员难以或不可能解决的情况。类

ClassLoader

可用于在包具有受限交互的情况下将具有相同名称的包彼此隔离，但不能以对天真程序透明的方式进行

通过首先拥有（或属于拥有）Internet域名的组织，例如

sun.com

，可以形成一个唯一的包名。然后逐个组件反转此名称，以在本例中获得

com.sun

，并使用此名称作为包名称的前缀，使用组织内制定的约定进一步管理包名称

软件包的名称并不意味着该软件包在互联网中的存储位置；例如，名为

edu.cmu.cs.bovik.cheese

的包不一定可以从Internet地址

cmu.edu

或从

cs.cmu.edu

或从

bovik.cs.cmu.edu

获得。建议的生成唯一包名的约定只是一种在现有的、广为人知的唯一名称注册表上附加包命名约定的方法，而不必为包名创建单独的注册表

---

XML名称空间也是如此。它们可以是任意字符串，但大多数情况下都是URL，它们通常甚至指向有用的信息（例如名称空间所属的XSD文件）。