Java包名称约定是否有缺陷？[关闭]

我们都熟悉反转域名的Java包名称约定。即www.evilcorp.com，按照惯例，将选择具有其java包com.evilcorp.stuff。

我越来越厌倦了这个。作为一名商业程序员，我一次又一次地遇到由于更名，收购或类似原因而导致的软件包名称完全不相关的情况。

在开源世界中，名称更改较少，因此有意义。然而，在我看来，许多（商业/内部）软件的保质期都比制造它们的组织的保质期长得多。

这个问题通常是通过采取营销部门的领导使用的名称的软件项目变得更糟大谈特谈他们使用是指某个项目。这个名称将在接下来的三个月内进行更改，以使皇帝的新衣服焕然一新。

因此，我几乎停止使用反向域作为程序包名称。当然，如果大规模进行，则存在名称冲突的风险，但是可以肯定的是，可以通过使用“唯一”软件名称，避免使用通用词或将反向域用于打算作为库出售/发布的项目来缓解这种情况。 。

其他想法？

我将引用Microsoft提供的关于名称空间（.NET的程序包）的建议，其中没有域名约定。我认为这对于Java软件包也是一个很好的建议，因为我不认为域名代表了稳定的身份。

命名空间名称的一般格式如下：

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

例如，Microsoft.WindowsMobile.DirectX。

给名称空间名称加上公司名称前缀，以防止来自不同公司的名称空间具有相同的名称和前缀。

请在名称空间名称的第二层上使用稳定的，与版本无关的产品名称。

不要使用组织层次结构作为命名空间层次结构中名称的基础，因为公司内的组名往往是短暂的。

名称空间名称是一个长期且不变的标识符。随着组织的发展，更改不应使名称空间名称过时。

即使您的公司名称不稳定，您也可以仅以产品名称开头。

您正在寻找另一个问题的解决方案，即如何通过将文件放在同一包中来避免程序员X和程序员Y互相踩脚趾。

“仅反转您的域名”以一种优雅的方式解决了这个问题，因为您可以肯定的是，如果X和Y不相关，它们将不会选择相同的程序包名称空间。

约定没有缺陷。人们有缺陷，正如您很好地说明了自己。

我可以想到2个好处：

1. 它避免了独立开发人员之间的冲突。域是唯一的。两个人可以为两个不同的项目命名相同，但是一个域只有一个所有者。
2. 这样可以更轻松地找到维护者。如果您继承使用某些开放源代码库的代码库，则最好将其放在可以帮助您找到它的程序包中。到现在为止，它并不重要，因为您肯定可以谷歌搜索它。但是十年前，这还不是很明显。

反向域名用于避免名称冲突，以防不同组织在其库中使用相同的类名。这是一个简单的解决方案，当然，它也有一些缺点（例如，同一组织中类的名称冲突该怎么办？）。

您没有义务使用它，这是约定俗成的规定。例如，某些Java程序员不遵守Java代码约定。

但是考虑替代方案。例如，您如何看待LogFactory的两个完全限定的类名：

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

要么

org.apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

因此，以我的想法，只要您喜欢任何东西，只要它包括常识和图书馆用户的注意事项即可。

当我开始一个新项目时，我总是坚持使用内部不变的名称，营销人员可能会或可能不会知道，因为它只会在源代码中引用。这样，我不必担心项目名称更改和名称空间污染。

这种情况适合我，因为源代码通常不是产品的重要组成部分，即项目通常是封闭源代码的专有系统。但是，在源代码为产品的开源项目中，这可能不可行。