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 的第一个版本。通过使用短包的层次结构限定导入的依赖项(例如类路径库)类，强调并保持我们自己的代码更简洁，可以轻松解决名称冲突。同样重要的是要记住，我们可以访问包级别的可见性，而如今这似乎被忽视了。

Answer 1

正如评论者指出的那样，这个约定是在 Java 诞生之初就建立的，以允许所有类使用全局命名空间。

Java 中影响这一点的一件事(与 TypeScript 和 JavaScript 不同)是类的名称及其包(以及它使用的所有类和包的名称)在编译时固定。如果不修改类的源代码，则无法将类重新组合到不同的层次结构中。因此，它不像解释型语言那样灵活，您可以在解释型语言中移动层次结构并更改加载代码的位置。

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

所以有充分的理由。

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

对 Java 中的每个属性使用 getter 和 setter 真的有意义吗？如果您很好地了解您正在使用的域，那么它很可能不会。但是如果停止这样做，您的代码对于团队中的其他成员来说就没有意义，您将不得不随着人们的加入而不断重新审视决策，等等。

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