抽象类的命名约定

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

作为替代方案：我更喜欢使用“种类”作为后缀来说明对象“属于或属于特定种族或家庭”（维基词典：-kind ）。

示例： DataProvider和ReflectiveDataProvider都是DataProviderKind

受到生物学的启发，其中例如“犬狼疮”属于“犬科动物”，大致翻译为“犬类”。

Answer 6

微软声明，在：

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

"✓ 考虑以基类的名称结束派生类的名称。这非常易读并且清楚地解释了关系。代码中的一些示例是：ArgumentOutOfRangeException，它是一种异常，和 SerializableAttribute，它是一个属性的种类。但是，在应用此准则时使用合理的判断很重要；例如，Button 类是一种 Control 事件，尽管 Control 没有出现在其名称中。

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