我的问题太奇怪了，以至于我现在甚至都拿不出更好的头衔。无论如何，我正在寻找一种命名2类的方法，但无法弄清楚什么是最好的方法。我确实知道这是一个基于意见的问题，但我坚持这一观点...因此，我希望对此表示任何意见
项目：A ->类名：呼叫（此类将代表从一个电话到另一电话的呼叫）其他类可能/可能不对该特定类进行子类化，如果这样，则这些子类的名称可能以某种方式与父类相关（CallState，CallEndPoint， CallSomething）。此类不会知道数据库的存在，可以说此类将成为通用电话驱动程序的一部分。
项目：B ->班级名称：电话？ （这将代表数据库中的实际表。该表将包含有关该呼叫的一些信息，例如呼叫ID，进入系统的时间等，以及其他可能/可能与该呼叫无关的信息）。此类实际上将充当RowMapper。
现在，这两个项目很可能会合并在一起，如果我对这些类进行相同的命名，那么我将在一个服务于2个不同目的的项目中以2个相同的名称结束。现在，如果我是唯一构建此应用程序的人，我可能会消化这个问题，但是如果多个人开始在该应用程序上工作，它将使其他人感到困惑，尤其是如果更多的类将遵循相同的模式。
答案 0 :(得分：2)
我不确定这是什么问题。您是否想知道是否可以给两个类相同的名称，还是一个坏主意？
通常用于要对数据库实体建模的类的约定是在类名后加上Entity。因此，您可以将第一类Call和第二CallEntity命名。这消除了有关类用途的一些歧义。大多数专业开发人员也会立即假设Entity类应该表示持久化的东西。
但是，如果您真的坚持给两个类都使用相同的名称。如果将它们放在单独的包装中，则完全有可能。您放入其中的包还可以使您更加清楚该类的意图。第一个可以是domain.model.Call，而第二个可以是domain.entity.Call
希望这会有所帮助：）
答案 1 :(得分：1)
现在，这两个项目很可能会合并在一起，并且 如果我给类命名相同，那么我将以2个相同的名字结束 一个项目中的课程可以满足2个不同的目的。
在同一个应用程序中，两个职责/数据不同的类需要具有相同的简单名称（即没有包），您确实应该将其视为要考虑的东西，很可能是要解决的。
当然，您可以在不同的程序包中定义这些类，但这真的可以解决您的问题吗？我不认为这将使事情变得不太清楚，因为客户端代码可能会使用错误的代码，并且每次开发人员在代码中操纵/读取Call时，他们都不得不怀疑自己当前正在处理“哪个调用”。
今天，您有两个不同的Call。有了这样允许的命名约定，为什么以后不使用新的命名约定呢？
真的，不是一个好主意。
问题的根源是设计应用程序的方式。
您将模型分为两部分：一个类中的不可知性持久性部分，另一个类中的数据持久性部分。这是一个选择（我个人会避免），但是如果您做出选择，则必须走到最后：清楚地区分每个类并使用不同的名称。此选择必须可见，而不仅仅是隐藏在包名称中。
例如 ：
Call (domain) and CallEntity (persistence)或以相反的方式CallDTO(domain) and Call(persistence)