命名子类的最佳实践

Question

我经常处于这样一种情况：我有一个由接口或类表示的概念，然后我有一系列扩展它的子类/子接口。

例如： 通用的“DoiGraphNode” 表示资源的“DoiGraphNode” 表示Java资源的“DoiGraphNode” 具有相关路径等的“DoiGraphNode”

我可以考虑三种命名惯例，并希望评论如何选择。

---

选项1：始终以概念的名称开头。

因此：DoiGraphNode，DoiGraphNodeResource，DoiGraphNodeJavaResource，DoiGraphNodeWithPath等。

亲：很清楚我在处理什么，很容易看到我有的所有选项

骗局：不是很自然？一切看起来都一样吗？

---

选项2：将特殊内容放在开头。

因此：DoiGraphNode，ResourceDoiGraphNode，JavaResourceDoiGraphNode，PathBaseDoiGraphNode， 等等。

亲：我在代码中看到它时非常清楚

Con：发现它可能很困难，特别是如果我不记得名字，缺乏视觉一致性

---

选项3：放入特殊内容并删除一些冗余文本

因此：DoiGraphNode，ResourceNode，JavaResourceNode，GraphNodeWithPath

亲：写作和阅读并不多 骗局：看起来像cr * p，非常不一致，可能与其他名称冲突

Answer 1

使用你喜欢的任何东西，这是一个主观的东西。重要的是要弄清楚每个类代表什么，名称应该是继承关系有意义的。我不认为编码名称中的关系是非常重要的;这就是文档的用途（如果你的名字适合于对象，人们应该能够很好地猜测从什么继承的内容）。

对于它的价值，我通常使用选项3，根据我的经验，查看其他人的代码选项2可能比选项1更普遍。

Answer 2

将它们命名为它们。

如果命名它们很难或含糊不清，那通常表明班级做得太多（单一责任原则）。

为避免命名冲突，请适当选择命名空间。

个人而言，我会使用3

Answer 3

您可以在编码标准文档中找到一些指导，例如，有C＃here的IDesign文档。

就个人而言，我更喜欢选项2.这通常是.NET Framework命名其对象的方式。例如，查看属性类。它们都以Attribute（TestMethodAttribute）结尾。对于EventHandlers也是如此：OnClickEventHandler是处理Click事件的事件处理程序的推荐名称。

我通常会尝试在设计自己的代码和接口时遵循这一点。因此，IUnitWriter生成StringUnitWriter和DataTableUnitWriter。这样我总是知道他们的基类是什么，它更自然地读取。自我记录代码是所有敏捷开发人员的最终目标，因此它似乎对我有用！

Answer 4

我通常命名类似于选项1，特别是当类将以多态方式使用时。 我的理由是首先列出最重要的信息。 （即，子类基本上是祖先的事实， （通常）扩展'添加'）。 我也喜欢这个选项，因为在排序类名列表时， 相关的课程将一起列出。 即我通常将翻译单元（文件名）命名为 类名称所以相关的类文件自然会一起列出。 同样，这对增量搜索很有用。

虽然我在编程生涯中早先倾向于使用选项2，但我现在避免使用它，因为你说它是“不一致的”并且看起来不是很正交。

当子类提供实质性扩展或规范时，或者如果名称相当长，我经常使用选项3。 例如，我的文件系统名称类是从String派生的 但是它们极大地扩展了String类并且有很大的不同 使用/含义：

从String派生的Directory_entry_name增加了广泛的功能。 从Directory_entry_name派生的File_name具有相当专门的功能。 从Directory_entry_name派生的Directory_name也具有相当专业的功能。

与选项1一起，我通常使用非限定名称作为接口类。 例如，我可能有一个类internce链：

• 文字（界面）
• Text_abstract（抽象（基础）泛化类）
• Text_ASCII（特定于ASCII编码的具体类）
• Text_unicode（特定于unicode编码的具体类）

我更喜欢界面和抽象基类自动首先出现在排序列表中。

Answer 5

从继承的概念出发，逻辑上更符合备选方案三。由于您正在专门化接口或类，因此名称应显示它不再使用基本实现（如果存在）。

有很多工具可以查看类继承的内容，因此表明类的实际功能的简洁名称将比尝试将过多的类型信息打包到名称中更进一步。