命名子类的最佳实践

Question

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

例如： 一个通用的“DoiGraphNode” 一个表示资源的“DoiGraphNode” 一个表示Java资源的“DoiGraphNode” 一个带有关联路径的“DoiGraphNode”，等等。

我能想到三种命名约定，并希望能得到选择的建议。

---

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

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

优点：非常清楚我正在处理什么，很容易看到我所有的选项。

缺点：不太自然？一切看起来都一样？

---

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

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

优点：在代码中看起来非常清晰。

缺点：找到它可能会很困难，尤其是如果我记不住名称，缺乏视觉一致性。

---

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

因此：DoiGraphNode、ResourceNode、JavaResourceNode、GraphNodeWithPath。

优点：写和读的内容不多。 缺点：看起来像垃圾，非常不一致，可能与其他名称冲突。

- Uri

Answer 1

用准确的名称来命名它们。

如果命名困难或模糊不清，往往意味着该类正在执行过多的操作（单一职责原则）。

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

个人而言，我会使用3个。

- Mitch Wheat

---

我也会选择第三个选项。在前两个选项中，存在着陷入“迷宫般的长名称，都略有不同”的危险，在这种情况下，你很难阅读它们，甚至记住哪个名称对应哪个概念。 - starblue

Answer 2

使用任何你喜欢的方式，这是一个主观的事情。重要的是要清楚地表明每个类代表什么，而且名称应该是使继承关系合理的。我并不认为在名称中编码关系非常重要; 这就是文档的作用（如果你的名称适合对象，人们应该能够猜测出什么继承自什么）。

就我个人而言，我通常使用选项3，从我的经验来看，查看其他人的代码时，选项2可能比选项1更普遍。

- David

Answer 3

我通常使用与选项1类似的命名方式，尤其是在类需要多态使用时。 我的理由是最重要的信息排在第一位。 （即子类基本上就是祖先，只是加了一些扩展）。 我也喜欢这个选项，因为在对类名进行排序时， 相关的类将会一起列出。 例如，我通常将翻译单元（文件名）与 类名相同，以便相关的类文件自然而然地排在一起。 类似地，在增量搜索中也很有用。

虽然我在编程生涯早期倾向于使用选项2，但现在我避免使用它，因为正如你所说的那样，它是“不一致”的，并且似乎不太正交。

当子类提供实质性扩展或规范化时，或者名称较长时，我经常使用选项3。 例如，我的文件系统名称类派生自字符串， 但它们大大扩展了字符串类并具有显着不同的用途/含义：

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

与选项1一起，我通常使用未限定的名称来命名接口类。 例如，我可能有一个类继承链：

• Text（一个接口）
• Text_abstract（抽象（基础）泛化类）
• Text_ASCII（具体针对ASCII编码的类）
• Text_unicode（具体针对unicode编码的类）

我相当喜欢接口和抽象基类自动出现在排序列表的最前面。

- Roger Nelson

Answer 4

你可以在编码标准文档中找到一些指导，例如C#的IDesign文档在这里。

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

我通常在设计自己的代码和接口时遵循这种方式。因此，IUnitWriter生成StringUnitWriter和DataTableUnitWriter。这样我总是知道它们的基类是什么，并且阅读起来更自然。自说明代码是所有敏捷开发人员的最终目标，所以对我来说似乎效果很好！

- x97mdr

Answer 5

选项三更符合继承的概念。由于你正在专门化接口或类，因此名称应表明它不再使用基本实现（如果存在）。

有许多工具可以查看一个类从哪里继承，因此指示类的真实功能的简洁名称比试图将太多类型信息打包到名称中更为有效。

- BlodBath