我有演示、域和数据模块。我正在从体育 api 获取足球运动员信息。我使用映射器类来映射模块层之间的数据类
我只是想知道在不同模块中命名数据类时的约定是什么
在我的数据层中，我将从 api 获取播放器并将其保存在本地。
Data Layer
local:
PlayerTable
repository:
PlayerEntity
Domain Layer
PlayerModel
Presentation
Player
我刚刚添加了Table、Entity 和Model 的后缀。对于 Presentation Player 来说就是这样。
只是想知道是否有任何特定的约定。我见过没有这种风格，但主要是保持一致。
只是想知道其他开发人员如何为他们的数据类命名。
感谢您的任何建议，
【问题讨论】：
标签： android architecture
没有关于如何命名类的官方命名方案。但在大多数语言中：
一些开发者在他们的变量前面加了这样的前缀：
我个人不使用这些前缀，因为我认为它们是在我们进行语法高亮之前的遗留物。今天，我们的 IDE 为所有内容着色，因此很容易区分类名、变量名等。
最终，如何组织代码由您决定，并且对于每个项目，您都会对其进行更改和改进。有时你会在一个有固定代码指南的团队中工作。有时，这样的代码指南甚至由 Lint 规则强制执行。
以下列方式之一考虑：
两年后从不看这段代码：你能通过读它的名字就知道这个类负责什么吗？
使类名尽可能短，但尽可能明确。例如。如果一个类已经在名为model 的包中，则不需要将其命名为PlayerModel。 Player 在大多数情况下应该足够了。
您的代码是一封写给未来自己的情书。如果你在几年后阅读它，你要么爱自己，要么恨自己（更常见的是后者..）
另一个不知道你的类做什么的开发者会明白它的职责吗？
也很重要：
永远不要害怕重构！如果你意识到一个名字很糟糕，那就重命名它。
也是一个很好的提示：
阅读几本关于简洁代码的书籍。我可以推荐“务实的程序员”，当然还有臭名昭著的“干净的代码”。
我希望这能给你一些关于这个主题的指导！玩得开心编码:)
更新：
如果您遇到在 1 个文件中使用两个具有相同名称的类的情况，大多数语言都提供“导入别名”。例如在 Java 中，您可以输入 import 语句
import some.file.from.network.Player as NetworkPlayer
import model.class.from.my.app as AppPlayer
然后，您可以使用别名 AppPlayer 和 NetworkPlayer 来引用文件中的 2 个不同的类，以使其清晰易懂。
【讨论】：
PlayerModel 与Player 的观点也是在考虑您的问题的情况下编写的。简短的回答：没有官方约定。最佳做法是创建自己的约定并在每个项目中严格遵守。
在我看来，清洁架构是一种关于如何以易于阅读、易于理解和明确划分职责的方式设计系统的哲学。
如果我们遵循这一理念，那么其中一些 模型/类/实例 永远不会交叉路径。这意味着 DataBaseModel 不会与 PresentationModel 存在于相同的上下文（java 文件、python 模块等）中。出于这个原因，看到人们用最明显的名字来实现它并将上下文作为分类器是很常见的。
例如，如果您有一个表示播放器的数据模型，则处理它的类的明显名称是 Player 并具有反映数据库处理性质的命名空间（或包），例如 database.Player 或 @987654323 @。
表示层也是如此。
关于实体，我遵循完全相同的规则。我总是有一个命名空间 core（我的个人偏好），我在其中存储实体和用例的所有代码。这个核心命名空间可以有其他子命名空间，并且不导入第三方代码（或保留最小的依赖项）。在这种情况下，如果我需要一个实体来代表一个玩家，我将它称为 Player。外部层与核心通信所需的接口在此处定义，并且仅依赖于实体。
外部层可以与实体代码通信的唯一情况是在实现核心接口时。在那里，我实际上遵循@muetzenflo 的建议，并在导入或使用命名空间（entities.Player）时为我的实体提供别名。
我不确定是否存在真正的约定，也不确定是否真的需要。最终目标是使代码易于理解、易于维护和易于开发。如果我们有理由放弃其中的一些指南，以使其更好、更可靠、更易于阅读和维护，那就这样吧。
【讨论】：