24

很久以前，我一直认为，在 java 中，将您拥有的域反转为包命名是愚蠢和尴尬的。

您在项目中使用哪个包命名？

4

9 回答 9

71

一旦你理解了约定存在的原因，它至少不应该感到愚蠢或尴尬。

这个方案做了两个重要的事情：

  • 您的所有代码都包含在其他人不会与之发生冲突的包中。您拥有自己的域名，因此它是孤立的。如果我们没有这个约定，许多公司都会有一个“实用程序”包，其中包含“StringUtil”、“MessageUtil”等类。如果你试图使用其他人的代码，它们会很快发生冲突。

  • 它的“反向”特性使得顶层的类目录布局非常狭窄。如果您展开一个 jar，您会看到“com”、“org”、“net”等目录，然后在每个目录下显示组织/公司名称。

（于 2021 年添加）如今，当这种类型的包命名用于第三方库时，这一点变得更加重要，这些库在构建过程中被传递引入，如果名称不是唯一的，则很容易发生冲突。如果每个人都遵守相同的约定，就不会有意外的碰撞。

（2021 年添加）相同的命名约定可用于应用商店上的应用程序 ID，以确保唯一性。

我们通常不会扩展 jar，但在早期的 java 开发中，这很重要，因为人们使用扩展的 dir 结构来进行小程序。

但是，现在这很好，因为源代码目录结构具有非常“自上而下”的感觉。您从最通用的（com、org、net...）到不太通用的（公司名称）再到更具体的（项目/产品/lib 名称）。

于 2008-10-09T21:23:50.370 回答
19

我实际上认为反向域名包命名是 Java 中更出色的约定之一。

于 2008-10-09T21:05:14.637 回答
5

如果它只是一个内部项目，并且代码不太可能被重用，那么我通常会使用简短的描述性名称。

但是，如果代码要在外部使用或在另一个项目中重用，那么我倾向于使用反向域方案。它确保不会有任何包名冲突。

于 2008-10-09T21:08:34.613 回答
5

我自己觉得很傻。com。部分实际上只添加了 4 个额外字符。另外，我认为在程序集/项目名称中使用公司名称也是错误的。我曾在太多与另一家公司合并或简单改名的地方工作过。

于 2008-10-09T21:17:23.987 回答
4

我认为这在很大程度上取决于正在编写的软件类型。比如我为一家小公司开发内部系统，所以我选择：

[company].[project].[sub].xyz(.abc)

哪里sub通常是client和common之一server。如果我在一家（商业）软件公司工作，我会更不愿意使用这个project位，因为项目开始时调用的应用程序和完成时调用的应用程序很可能是两个完全不同的东西！这是为了：

oak.lang.Object
于 2008-10-11T00:23:28.887 回答
1

是的，我使用反向域作为包的开头，然后是其他管理信息（项目、部门等）。域的使用最大限度地减少了供应商/公司/FOSS 项目之间发生冲突的机会。由于域，我的“数据”包不会与另一家公司的数据包发生冲突。

我还使用了删除 tld 的惯例，用于内部工作或不适合外部使用的类（可能是未记录的支持库等）。这通常会让其他开发人员清楚不同的规则或策略可能适用于代码块。

使用反向域比不遵循任何规则或既定模式的任意命名空间要少得多。

于 2008-10-09T21:05:44.417 回答
1

我为我的所有项目都这样做，我什至把它带到我的命名空间的 .NET 应用程序中。

于 2008-10-09T21:10:21.817 回答
1

是的，我什至设计了一个使用反向域命名约定在 JavaScript 中创建命名空间的方案，它使查找特定资产及其负责的内容变得更加容易，并且有助于防止名称冲突。

于 2008-10-09T21:20:33.090 回答
1

它非常有用并被其他人复制（例如 XML Schema）。

它在“大”（鉴于 WWW）中很有用，但在跨部门（即在小）中可能更有用。对于较小的项目，它可能看起来很臃肿，但它就像保险一样：当你以后需要它时它就在那里。

于 2008-10-09T22:16:51.480 回答