Java 包命名方案：TLD 真的那么重要吗？ [关闭]答案

【问题标题】：Java package naming scheme: Is the TLD really that important? [closed]Java 包命名方案：TLD 真的那么重要吗？ [关闭]
【发布时间】：2011-07-09 02:03:38
【问题描述】：

只是我，还是 Java 包命名约定中的 TLD 非常无关？我的意思是，如果您在com.example.package 和org.example.package 之间确实存在命名空间冲突，而没有TLD，那么无论如何您都会感到困惑。为什么命名空间冲突的权衡混淆？肯定是编译器吐出错误/警告比它兴高采烈地试图编译一个导入错误包的程序更好？

只是我在大会上的两分钱。坦率地说，你不会真的在 org.xml 之间发生命名空间冲突。和 com。无论如何，两个同名的 java 包不太可能由具有相同域但不同 tld 的两家公司编写。

【问题讨论】：

标签： java namespaces tld

【解决方案1】：

我问了一个关于包名的问题，Jon Skeet（不管那个人是谁）有一个很好的评论要说

来自：Hyphenated company name in Java packages

说实话，我希望 Java 没有走这条路公约。我想知道有多少名为“com”或“org”的目录与单个成员存在 - a 更有意义的子目录名字。

【讨论】：

提出了一个有效的观点——这个约定影响目录以及导入声明的事实（我在原始帖子中忽略了这一点）。当面对一个充满包的目录并且我必须首先选择 com/ 或 org/ 时，如果我不隐式知道该包使用哪个 TLD，我应该如何找到它？当然，这对开发人员影响不大，因为它主要由工具处理，但我相信这种情况最终会出现......

【解决方案2】：

没有。

证明：存在另一种非常流行的语言，有很多库，都在简单的命名空间下。而且他们不存在名称冲突的问题。

【讨论】：

【解决方案3】：

有时它可能很重要，但更多的是声望，而不是实际的工程原因。它可以比作画家在画角的签名，上面写着“我做了这个。”，当你表达你的担忧和/或意见时，这会让你引人注目.

作为一个例子，当 Apache Software Foundation resigned 从 JCP 时，每个人都知道这对他们的工作的直接影响，因为他们使用的所有外部 3rd 方库都包含域：拥有大量 org.apache.* 导入的人知道他们真的应该倾听公告并开始密切关注它，因为它最终会对他们产生影响。

同样，您可以利用贵公司的良好声誉来宣传图书馆；如果我要向您宣传来自某个随机方的一组收藏库，哪个听起来更好，common.collect 下的那个还是com.google.common.collect 下的那个？

将域部分添加到包中与实际实践几乎没有关系，它是关于承担责任，并为自己和所做的事情感到自豪。它关乎开放，关乎分享，关乎成为社区的一员，关乎在全球 1300 万左右的软件开发人员中，你。

【讨论】：

关键是为什么com？ google.common.collect 的声誉真的会降低吗？
@glowcoder：更笼统地思考一下，TLD:s 之间可能存在重大差异，这可能会完全误导人们。像魔鬼的拥护者那样阅读一个例子对你没有任何好处。
@glowcoder 完全正确。正如我在 OP 中指出的那样，com.google.common.collect 和 org.google.common.collect 是具有不同命名空间（但命名空间名称相似）的竞争库，可能会让开发人员感到困惑。

【解决方案4】：

如果您的包不是库（或者它们只是您自己公司的库），那么它们永远不会被淘汰，因此您不必遵循任何包协议。事实上，在独立应用程序中，我只使用一个简短的包名称并将所有内容都粘贴在其中。如果它们使用相同的包声明，这将简化来自不同程序的常用文件的差异或校验和。这是我发布的一个问题：Generic Java Package Name

【讨论】：

【解决方案5】：

com. 或 org. 对软件包名称并不重要，只是“使用您公司的域名”是一个不错的简单经验法则。

【讨论】：

当然，从表面上看它很好很简单，但我仍然认为com.example.package 与org.example.package 很容易在这种不太可能发生的冲突发生时产生混淆。单独使用它不太可能使 TLD 变得无关紧要，但冲突引起的混乱是删除它的更多理由。

【解决方案6】：

就像你说的，这只是一个约定。它的设计不是完美的。域可以易手，这也会导致冲突。

【讨论】：

【解决方案7】：

我只是在编写软件时忽略它，但 TLD 确实有助于使包独一无二。

【讨论】：