命名 Java 包的建议方法是什么？答案

【问题标题】：What is the suggested way to name Java packages?命名 Java 包的建议方法是什么？
【发布时间】：2011-08-03 04:09:16
【问题描述】：

我见过很多像com.mycompany.someapp 这样的例子。似乎是域的反面。这对我来说实际上很有意义。

但归根结底，这真的很重要吗？我们是一家小商店，所以也许我们看不到正确域名命名的好处。

那么，将其命名为与域匹配是一种好习惯吗？如果有，为什么？

【问题讨论】：

@see Java Tutorial
不使用正确的域名命名有什么好处吗？
另见softwareengineering.stackexchange.com/questions/75919/…
哇。这差不多是 6 年前的事了。我从 .NET 到 Java 的过渡已经完成。大声笑

标签： java naming-conventions

【解决方案1】：

摘自 Andrew 评论中指向 Naming a Package (Java Tutorial) 的链接：（我声称对以下内容不具有独创性或所有权）。

命名包

随着世界各地的程序员使用 Java 编程语言编写类和接口，很可能许多程序员会为不同的类型使用相同的名称。 事实上，前面的示例就是这样做的：它定义了当 java.awt 包中已经有一个 Rectangle 类时，一个 Rectangle 类。尽管如此，如果两个类位于不同的包中，编译器仍允许它们具有相同的名称。每个 Rectangle 类的完全限定名包括包名。即graphics包中Rectangle类的全名是graphics.Rectangle，java.awt包中Rectangle类的全名是java.awt.Rectangle。

除非两个独立的程序员为他们的包使用相同的名称，否则这很有效。是什么阻止了这个问题？

命名约定

包名全部小写以避免与类或接口的名称冲突。
公司使用 [他们的] 反向 Internet 域名来开始其包名称 - 例如，com.example.mypackage 表示由 example.com 的程序员创建的名为 mypackage 的包。
名称发生在单个公司内的冲突需要按照该公司内的惯例处理，可能通过在公司名称后包含地区或项目名称（例如，com. example.region.mypackage)。
Java 语言本身的包以 java 开头。或 javax。

在某些情况下，互联网域名可能不是有效的软件包名称。如果域名包含连字符或其他特殊字符，如果包名称以数字或其他非法用作 Java 名称开头的字符开头，或者如果包名称包含保留的 Java 关键字，则会发生这种情况，比如“int”。在这种情况下，建议的约定是添加下划线。例如：

合法化包名域名包名前缀
连字符名称.example.org org.example.hyphenated_name
example.int int_.example
123name.example.com com.example._123name

编码愉快。

【讨论】：

如果你是一个没有域名的单身开发者怎么办？
@Bubby4j 编造一个，不是真的 :-) 关键是避免冲突——只要确保你的冲突。例如，过去我曾使用pst. 作为我的“TLD”。虽然不能保证这在未来永远是独一无二的，但它创造了一个逻辑分离，并且出于所有实际目的，确保了唯一性。大型项目也可以选择自定义“TLD”，例如使用 scala. 的 Scala（这与 Apaches 下的任何东西都相反；-)

【解决方案2】：

匹配域可以让您更有信心避免出现名称冲突。对于 3rd 方库的设计者来说，这可能比您和您的应用更重要。

【讨论】：

【解决方案3】：

是的，这是Java Language Specification, section 7.7 中建议的约定。

如果不使用唯一的包名，则包名冲突可能会在远离冲突包的创建点发生。这可能会造成用户或程序员难以或不可能解决的情况。 ClassLoader 类可用于将同名的包相互隔离，在这些情况下，包的交互受到限制，但对幼稚的程序来说不是透明的。

您首先拥有（或属于拥有）互联网域名（例如 sun.com）的组织，从而形成一个唯一的包名称。然后，您逐个组件地反转此名称，在此示例中获得 com.sun，并将其用作您的包名称的前缀，使用您组织内制定的约定来进一步管理包名称。

您没有必须遵守约定，但这通常被认为是好的做法。毕竟，假设在未来的某个时候，您希望将您的一些代码作为开源发布——但您希望避免命名冲突。在这一点上，您真的应该遵循与其他人相同的约定 - 而且从一开始就这样做伤害...

【讨论】：

【解决方案4】：

使用域名背后的想法是避免包装中的命名空间冲突。这只有在每个人都遵守约定的情况下才有效。所以，是的，公约很重要。也就是说，如果您从不打算将代码作为 API 导出或提供给第三方，那么使用您喜欢的任何包名称都可能没有什么缺点。

【讨论】：

【解决方案5】：

实际上我喜欢它有几个原因：

它让用户只需查看包名称即可轻松访问
它避免了数据包名称之间的冲突（即两个“媒体”数据包很可能会发生冲突）
它有助于识别不同软件的同一作者
它使包名称的长度大致相同（好吧，这只是一个美学点，但我喜欢它！）

除此之外，JLS 也推荐它。这不是一个要求，但是当它实际上是 0 努力时，除非有充分的理由，否则我会这样做。

也许要问一个更好的问题是为什么不你想遵循那个约定？如果没有真正的原因，跟随它没有坏处！

【讨论】：

【解决方案6】：

主要目的是保证包名称的唯一性，但如果你永远不会发布代码供他人使用，那可能没关系，但坚持约定和担心有很多话要说关于重要的事情。否则有一天，当你意识到你有一个很棒的图书馆想要分享时，你可能会因为逆流而上而自责。

【讨论】：

【解决方案7】：

是的，始终使用命名方案是明智的。作为一个反例，假设每个人都会为其类使用默认包。

User 或Address 等公共类会被多个库使用，但最终在运行时环境中只能有一个特定名称的类。（粗略地说，并不完全正确。）

在大型项目中，您可能会使用许多外部库，例如 Apache Commons、Google Guava、Spring、Hibernate、Terracotta。好在这些库都使用自己的命名空间，这样它们的内部类就不会意外冲突。

【讨论】：