2 类 同名，服务不同
2 Classes with the same name, serving different purposes
我的问题太奇怪了，我现在想不出一个更好的标题。无论如何，我正在寻找一种命名 2 classes 的方法，但无法弄清楚什么是最好的方法。我知道这是一个基于意见的问题，但我坚持这个......所以我很感激对此的任何意见
项目：A
-> Class name: Call（这个 class 代表从一部电话到另一部的电话） Other classes may/may not subclass this particular class 如果是这样的话，这些子 class 的名称可能会以某种方式与 parent class （CallState、CallEndPoint、CallSomething）相关。这个 Class 不知道数据库的存在，可以说这个 class 将成为通用电话 driver.
的一部分
项目：B
-> Class 姓名：打电话？ （这将代表数据库中的实际 table。table 将包含有关呼叫的一些信息，如呼叫 ID、进入系统的时间等，还有其他 may/may 没有的信息与通话有关）。这个 class 本质上将用作 RowMapper。
现在，这 2 个项目很可能会合并在一起，如果我将 classes 命名为相同的，那么我最终会在一个项目中得到 2 个相同的名称 classes服务于 2 个不同目的的项目。现在，如果我是唯一一个构建此应用程序的人，我可能会理解这一点，但如果多人开始在该应用程序上工作，就会让其他人感到困惑，尤其是如果更多 classes 将遵循相同的模式。
我不太确定这里的问题是什么。你想知道是否可以给 2 class 起一个相同的名字，或者只是想知道这是否是个坏主意？
通常用于 class 用于对数据库实体建模的约定是在 class 名称后缀 Entity。因此，您可以命名第一个 class Call 和第二个 CallEntity。这消除了关于 classes 目的的一些歧义。大多数专业开发人员也会立即假设实体 class 应该代表持久化的东西。
然而，如果你真的坚持要给两个class起同样的名字。如果您将它们放在单独的包中，那是完全可能的。您将它们放入的包还可以更清楚地说明 class 的意图。第一个可以是 domain.model.Call，而第二个可以是 domain.entity.Call
希望这对您有所帮助:)
Now, these 2 projects most likely will be combined down the line, and
If I name the classes the same I would then end up with 2 same name
classes in a single project serving 2 different purposes.
当在同一个应用程序中，两个具有不同 responsibilities/data 的 class 需要具有相同的简单名称（即没有包）时，您确实应该将其视为需要考虑的事情并且很可能修复。
当然你可以在不同的包中定义这些 classes 但它真的能解决你的问题吗？我不认为。这会使事情变得不那么清晰，因为客户端代码可能会使用错误的代码，并且每次开发人员 manipulate/read Call 在代码中他们不得不怀疑 "which Call" 他们目前正在应对。
今天你有两个不同的 Call。有了这样宽松的命名约定，为什么不在将来使用新的命名约定？
真的，这不是个好主意。
问题的根源在于您设计应用程序的方式。
您将模型分成两部分：class 中的不可知持久性部分和另一个 class 中的数据持久性部分。这是一个选择（我个人避免），但如果你做出这个选择，你必须走到最后：用不同的名字清楚地区分每个 class。此选择必须可见，不能仅隐藏在包名称中。
例如 ：
Call (domain) and CallEntity (persistence) 或相反 CallDTO(domain) and Call(persistence)
我的问题太奇怪了，我现在想不出一个更好的标题。无论如何，我正在寻找一种命名 2 classes 的方法，但无法弄清楚什么是最好的方法。我知道这是一个基于意见的问题，但我坚持这个......所以我很感激对此的任何意见
项目：A -> Class name: Call（这个 class 代表从一部电话到另一部的电话） Other classes may/may not subclass this particular class 如果是这样的话，这些子 class 的名称可能会以某种方式与 parent class （CallState、CallEndPoint、CallSomething）相关。这个 Class 不知道数据库的存在，可以说这个 class 将成为通用电话 driver.
的一部分项目：B -> Class 姓名：打电话？ （这将代表数据库中的实际 table。table 将包含有关呼叫的一些信息，如呼叫 ID、进入系统的时间等，还有其他 may/may 没有的信息与通话有关）。这个 class 本质上将用作 RowMapper。
现在，这 2 个项目很可能会合并在一起，如果我将 classes 命名为相同的，那么我最终会在一个项目中得到 2 个相同的名称 classes服务于 2 个不同目的的项目。现在，如果我是唯一一个构建此应用程序的人，我可能会理解这一点，但如果多人开始在该应用程序上工作，就会让其他人感到困惑，尤其是如果更多 classes 将遵循相同的模式。
我不太确定这里的问题是什么。你想知道是否可以给 2 class 起一个相同的名字，或者只是想知道这是否是个坏主意？
通常用于 class 用于对数据库实体建模的约定是在 class 名称后缀 Entity。因此，您可以命名第一个 class Call 和第二个 CallEntity。这消除了关于 classes 目的的一些歧义。大多数专业开发人员也会立即假设实体 class 应该代表持久化的东西。
然而，如果你真的坚持要给两个class起同样的名字。如果您将它们放在单独的包中，那是完全可能的。您将它们放入的包还可以更清楚地说明 class 的意图。第一个可以是 domain.model.Call，而第二个可以是 domain.entity.Call
希望这对您有所帮助:)
Now, these 2 projects most likely will be combined down the line, and If I name the classes the same I would then end up with 2 same name classes in a single project serving 2 different purposes.
当在同一个应用程序中，两个具有不同 responsibilities/data 的 class 需要具有相同的简单名称（即没有包）时，您确实应该将其视为需要考虑的事情并且很可能修复。
当然你可以在不同的包中定义这些 classes 但它真的能解决你的问题吗？我不认为。这会使事情变得不那么清晰，因为客户端代码可能会使用错误的代码，并且每次开发人员 manipulate/read Call 在代码中他们不得不怀疑 "which Call" 他们目前正在应对。
今天你有两个不同的 Call。有了这样宽松的命名约定，为什么不在将来使用新的命名约定？
真的，这不是个好主意。
问题的根源在于您设计应用程序的方式。
您将模型分成两部分：class 中的不可知持久性部分和另一个 class 中的数据持久性部分。这是一个选择（我个人避免），但如果你做出这个选择，你必须走到最后：用不同的名字清楚地区分每个 class。此选择必须可见，不能仅隐藏在包名称中。
例如 ：
Call (domain) and CallEntity (persistence) 或相反 CallDTO(domain) and Call(persistence)