Java包结构约定

Question

我正在使用 Typescript 和 Javascript，我停下来思考了一下命名空间以及我们如何在 Java 中组织代码。

现在，我经常看到多个具有相同目的的类，只是用于不同的数据，被放置在不同名称的不同包中。

虽然将这些类放在不同的包中是保持项目/模块处于良好状态的好习惯，但为什么我们必须给它们不同的名称？我的意思是，它们的目的是一样的。

我可以自己回答这个问题：因为我们经常在同一个单元中使用这些类，它们会发生冲突，因此需要一个很长的完整包规范。

但是我们不是违反了 DRY 原则吗？我们应该使用我们的目录（包）结构来了解这些类在哪个域空间中工作。

正如我在上面所写的，我想许多开发人员并没有遵守这个 DRY 原则，只是为了避免长包名。那么，我们为什么要创建那些 monstruos 包层次结构呢？
谷歌搜索"Java packages best practices" 会得到如下建议：

com.mycompany.myproduct.[...]

这些建议来自哪里？我们不是在浪费空间吗？
我们显然不想每次都这么写。

MyClass myInstance;
com.mycompany.myproduct.mypackage.MyClass myOtherInstance;

但它本来可以

myfeature.MyClass myInstance
myotherfeature.MyClass myInstance;

我们甚至可以为两者指定完整的包。
那么，这些最佳实践从何而来？

如前所述，这个约定可以追溯到 Java 的第一个版本。 名称冲突可以通过使用它们的 short 包的层次结构限定导入的依赖项（例如类路径库）类来轻松解决，强调并保持 我们的自己的代码更清晰。同样重要的是要记住我们可以访问包级别的可见性，这在当今似乎被忽视了。

Answer 1

正如评论者指出的那样，这个约定是在 Java 的一开始就建立起来的，允许一个全局命名空间用于所有类。

影响这一点的 Java 有一点——它与 TypeScript 和 JavaScript 不同——类的名称及其包（以及它使用的所有类和包的名称）固定在编译时。您不能在不修改其源代码的情况下将类重新组合到不同的层次结构中。所以它不像解释语言那样灵活，您可以移动层次结构并更改加载代码的位置。

例如，您当然可以将应用程序中的所有内容都放在顶级包中，并且非常有信心您会侥幸成功。只要每个人else都遵循现有的约定，您就可以做到这一点。一旦他们停止这样做，并且库开始将类放在他们想要的任何地方，您就会遇到冲突，您将不得不更改您的应用程序。或者库会开始相互冲突，如果你没有源，你将无法真正修复它。

所以有充分的理由。

我基于意见的部分——坚持约定和语言（或平台）的文化是有道理的。在我们看来，即使这些约定很愚蠢。有一个地方可以打破它们，但优势必须非常大。其他开发人员将习惯于约定，工具会对约定做出假设……通常顺其自然是有意义的。

对 Java 中的每个属性都使用 getter 和 setter 真的有意义吗？如果您了解您正在使用的域，那么它很可能不会。但是停止这样做，你的代码对你团队的其他成员没有意义，你必须在人们加入时不断地重新审视这个决定，等等。

如果这是一个单人项目，并且永远都是，当然，你可以做你想做的事。