抽象类的命名约定

Question

我清楚地记得，曾经，微软推行的指导方针是在抽象类中添加“Base”后缀，以消除它是抽象的事实。因此，我们有这样的课程 System.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, System.Windows.Forms.ButtonBase, ， 而且当然， System.Collections.CollectionBase.

但我注意到，最近框架中的许多抽象类似乎没有遵循这个约定。例如，以下类都是抽象类，但不遵循此约定：

• System.DirectoryServices.ActiveDirectory.DirectoryServer

• System.Configuration.ConfigurationElement

• System.Drawing.Brush

• System.Windows.Forms.CommonDialog

这就是我在几秒钟内就能鼓起的力量。所以我去查找官方文档的内容，以确保我没有疯。我找到了 类、结构和接口的名称 在 MSDN 上 开发类库的设计指南. 。奇怪的是，我找不到任何提及在抽象类名称末尾添加“Base”的指南。该指南不再适用于框架 1.1 版本。

那么，我会失去它吗？这个指导方针曾经存在过吗？难道就这样一声不吭地被抛弃了吗？过去两年我自己创建长类名是否毫无意义？

有人在这里扔了我一根骨头。

更新我没疯。指导方针是存在的。 克日什托夫·奇瓦利纳 (Krzysztof Cwalina) 在 2005 年对此表示不满。

Answer 1

在 框架设计指南 第 174 页指出：

避免 如果该类打算在公共 API 中使用，则使用“Base”后缀命名基类。

还 ： http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx

Answer 2

另外，如果抽象类有一些要使用的静态成员，“基类”可能会变得丑陋。

Answer 3

我不记得有这样的指导方针。我相信您应该使用有意义的命名。有时抽象类只是为了给某些类（作为工具）提供通用功能而设计的，我认为应该带有后缀。但是，在某些情况下，您希望将它用作多态层次结构的基础，但它本身并不完整。在这些情况下，我建议像普通类一样命名。

如您所见，您可能不会声明接受 ButtonBase 作为参数的方法。它旨在为子类提供最少的功能。但是，您可能会治疗 ConfigurationElement 作为一个具有不同形式的实体，但它本身并不完整（因此它是抽象的）

Answer 4

有时 Base 仍然是必要的，特别是当您同时提供具体类和抽象类供某人扩展以创建具体实现时。
例如控制器和控制器底座 （实际上 Controller 也是抽象的，但提供的功能比 ControllerBase 多得多）

当针对接口进行编程时，基后缀很难看，因此我认为当抽象类主要像接口一样使用时，不使用它的微软指南适用。可能他们所说的公共 API 是什么意思。

关键是，在某些情况下，没有比使用 Base 后缀更好的替代方法。

Answer 5

我理解避免使用基本后缀的倾向，但我也理解需要 一些 后缀。现在，一条评论 本文的 建议使用“类型”作为后缀作为不使用任何后缀的第二选择。我认为这令人困惑，但“这样一个不承诺的词往往表明它是一个不承诺的类”的想法一直困扰着我。

作为备选： 我更喜欢使用“Kind”作为后缀来表示该对象“属于或属于特定种族或家庭”（维基词典：-种类).

例子： DataProvider 和 ReflectiveDataProvider 都是 DataProviderKind

受到生物学的启发，例如“canis lupus”属于“Canoidea”科，大致翻译为“狗类”。

Answer 6

微软表示，在：

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces

“✓ 考虑以基类的名称结尾派生类的名称。这非常易读并且清楚地解释了其中的关系。代码中的一些示例是：ArgumentOutOfRangeException，它是一种 Exception，而 SerializedAttribute，它是一种 Attribute。然而，在应用本指南时使用合理的判断很重要；例如，Button 类是一种 Control 事件，尽管 Control 并未出现在其名称中。”

一般来说，这隐含地排除了在名称中使用“Base”的可能性。