从语义上来说，比`util`更合适的软件包名称是？

就像一个稻草人考虑的那样，java.util它是各种课程的垃圾场，在大多数情况下，除了让他们在那里的人懒惰或没有动力为他们的课程提出一个语义上更正确的软件包名称外，大多数情况下没有其他共同点。

作为一个示例，使用该类UUID在该语义上正确的包名称是什么？

我正在努力实现自己的UUID类，以使其更加轻巧。我不想使用me.myproject.util.UUID我的包裹名称。

我考虑过，me.myproject.rfc4122.UUID但这并不意味着使用的语义UUID。

我也考虑过，me.myproject.uuid.UUID但我不喜欢重言式，尽管在Python中将同名的类放入模块中是一种流行的方法，而packagesJava在语义上并不等同modules于Python。

我也考虑me.myproject.UUID但拒绝了它，因为我不想用不相关的内容污染名称空间的那一部分。这只是使问题更上一层楼。

我也考虑过，me.myproject.lib.UUID但这并没有更多的语义含义.util，只是重命名了问题。

semantics：与意义有关的语言学和逻辑学分支。

试图将每个类放入具有该类的语义正确名称的包中的问题是，它倾向于导致包含很少类的包，有时甚至只包含一个类。这又导致了很多包装。

包命名的一种更实用的方法是简单地帮助您查找内容。将经常使用的东西保存在一个地方，您总是知道在哪里可以找到所有的东西，从而避免了它们的麻烦，因此可以更轻松地找到很少使用的东西。因此，您实际上并不需要在其所包含的每个类的语义上正确的程序包名称，而只需要在语义上并非正确的程序包名称。显然，“ util”包名称是根据以下思路选择的：它不是所包含类在语义上正确的名称，但在语义上也不是不正确的，这就足够了。

因此，如果您的这种UUID类型注定仅由该特定应用程序使用（如您计划将其放在“ myproject”下的事实所证明），则它可能是您的“模型”的一部分项目。您应该已经有了一个“模型”包，其中包含与您的持久性实体相对应的所有类的集合，其中许多类之间可能存在关系，而UUID可能是实现这些关系的方法。另外，您的UUID可能知道如何保持自身，对吗？而且，您的UUID可能只能作为模型实体的成员找到，对吗？因此，您的模型包装可能是最好的选择。

否则，如果您的UUID类型也可以在其他项目中使用，则需要将其视为某些框架的一部分。因此，它可能位于该框架的根源文件夹中，或者位于MainMa建议的某些“类型”子包中，或者甚至位于该框架的某些名为“ util”或“ misc”的子包中。没有错。

包的目的是根据某些条件将类分组（按类型/层的包与按功能的包等）。我真的没有发现只为一个类创建包的意义-尤其是如果您不希望将来该包中还会有其他类。

同样，我认为“ util”包名称并非完全没有意义-只是按照特定的标准对类进行分组-对我而言，“ util”类意味着它不是应用程序领域的一部分，但也不是应用程序领域的一部分框架（它不会影响应用程序的结构）。它基本上只是（非）标准库的扩展。

在这种情况下，将这个UUID类放入“ util”包中不会有问题。如果还会有其他一些与UUID相关的实用程序类（例如用于生成UUID的单独类），则很容易为它们重构和创建“ util.uuid”包（除非您正在创建库，并且UUID将成为公开接口的一部分） ，那么您需要有点“前瞻性”）。

鲍勃叔叔有一些包装分离的准则。

前三个包装原则是关于包装内聚力的，它们告诉我们在包装内放入什么：

1. 再利用的颗粒是释放的颗粒
2. 一起变化的类打包在一起
3. 一起使用的类打包在一起

那么，回答您的问题，谁/将使用 UUID类，将其作为属性或在其中调用操作？你的依赖图怎么样？UUID将与其他哪些类一起使用？

根据您的答案，也许您应该将其称为me.myproject.identity程序包，me.myproject.serialization程序包me.myproject。DTO甚至完全是其他东西。也许应该将UUID类与模型保持在一起，并将其放入已经拥有的包中，例如me.myproject.models。

首先，对于我来说，对于包名或类名来说，UUID（带有大写字母）似乎是一个非常糟糕的主意，因为从一种方式强制执行的所有样式中，所有大写名称都与“常量”相关联。包是用来组织东西的，最简单的命名包的方法是通过其持有的类的值：

• 您可以选择按类别的bussines值分隔类别，例如com.example.identifier；
• 或例如通过其技术价值com.example.uuid。

简化IT