抽象类的命名约定

我清楚地记得，曾经有一次，Microsoft提出的指导方针是将“ 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年加入了这项计划。

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

如果要在公共API中使用基类，请避免使用“ Base”后缀命名基类。

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

同样，如果抽象类有一些静态成员将要使用，则“ Base”会变得很丑陋。

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

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

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

当针对接口进行编程时，基本后缀很难看，因此，我认为，当抽象类主要用作接口时，Microsoft准则不使用它。它们可能是Public API的意思。

关键是在某些情况下，没有比使用Base后缀更好的选择了。

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

作为替代方案：我更喜欢使用“种类”作为后缀，以将该对象声明为“属于或属于指定种族或家庭”（维基百科：-kind）。

示例：DataProvider和ReflectiveDataProvider都是DataProviderKind

受生物学启发，例如“犬红斑狼疮”属于“ Canoidea”家族，该家族大致翻译为“狗食”。

Microsoft声明：

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

“✓考虑到派生类的名称以基类的名称结尾。这很容易理解，并且清楚地说明了这种关系。代码中的一些示例包括：ArgumentOutOfRangeException，这是一种Exception； SerializableAttribute，是一种但是，在应用此准则时必须做出合理的判断；例如，Button类是Control事件的一种，尽管Control并未出现在其名称中。”

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