2 个同名的类，服务于不同的目的

Question

我的问题太奇怪了，我现在想不出更好的标题。无论如何，我正在寻找一种方法来命名 2 个类，但无法弄清楚什么是最好的前进方式。我明白这是一个基于意见的问题，但我坚持这个......所以我很感激对此的任何意见项目：A -> 类名：Call（这个类将代表从一部电话到另一部电话的呼叫）其他类可能/可能不会子类化这个特定类，如果是这样，这些子类的名称可能会以某种方式与父类相关（CallState 、CallEndPoint、CallSomething）。这个类不会知道数据库的存在，可以说这个类将是通用电话驱动程序的一部分。项目：B -> 类名：调用？（这将代表数据库中的实际表。该表将包含有关呼叫的一些信息，例如呼叫 ID、进入系统的时间等，以及可能/可能与呼叫无关的其他信息）。此类将本质上用作 RowMapper。现在，这两个项目很可能会合并在一起，如果我将这些类命名为相同的名称，那么我最终会在一个项目中得到 2 个相同名称的类，用于 2 个不同的目的。现在，如果我是唯一一个构建此应用程序的人，我可能会消化这一点，但是如果多人开始在该应用程序上工作，那么其他人就会感到困惑，尤其是如果更多的类将遵循相同的模式。

Answer 1

现在，这两个项目很可能会合并在一起，如果我将这些类命名为相同的名称，那么我最终会在一个项目中得到 2 个相同名称的类，用于 2 个不同的目的。

当在同一个应用程序中，两个具有不同职责/数据的类需要具有相同的简单名称（即没有包）时，您确实应该将其视为需要考虑并且很可能修复的东西。
当然，您可以在不同的包中定义这些类，但它真的能解决您的问题吗？我不认为。它会使事情变得不那么清楚，因为客户端代码可能会使用错误的代码，并且每次开发人员操作/读取Call代码时，他们都必须想知道他们当前正在应对“哪个调用”。
今天你有两个截然不同的Call. 有了如此宽松的命名约定，为什么将来不使用新的命名约定呢？
真的，这不是个好主意。

问题的根源在于您设计应用程序的方式。
您将模型分为两个部分：一个类中的不可知持久性部分和另一个类中的数据持久性部分。这是一个选择（我个人避免这样做），但如果你做出这个选择，你必须坚持到底：用不同的名字清楚地区分每个班级。此选项必须可见，不能仅隐藏在包名称中。
例如： Call (domain) and CallEntity (persistence)或以相反的方式CallDTO(domain) and Call(persistence)