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真的有意义吗？如果您了解使用得很好的域，那么可能就不会很好。但是，别再这样做了，您的代码对团队的其他成员将毫无意义，随着人们的加入，您将不得不不断地重新考虑这个决定，等等。

如果这是一个人的项目，而且总会是，那么您可以做自己想做的事。