抽象类的命名约定

我清楚地记得，曾经有一段时间，微软推行的指导方针是向抽象类添加“ 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版本。

我是不是疯了？这个指南曾经存在过吗？它就这么一声不响地被遗弃了吗？过去两年我一直在自己创建长的类名，结果一无所获吗？

谁能给我点好处。

更新 我没有疯，这个指导方针是存在的。2005年，Krzysztof Cwalina 抱怨过这个问题。

38167 次浏览
小开

I don't remember such a guideline. I believe you should use the naming that makes sense. Sometimes the abstract class is only designed to provide common functionality to some classes (as a tool), which I think should have the suffix. However, in some cases, you want to use it as the base of a polymorphism hierarchy which it's not complete itself. In those cases I suggest naming like a normal class.

As you see, you won't probably declare a method that accepts a ButtonBase as parameter. It's designed to provide minimal functionality for subclasses. However, you might treat a ConfigurationElement as an entity that has different forms but it is not complete on itself (and hence it's abstract)

小开
最佳答案

In Framework Design Guidelines p 174 states:

Avoid naming base classes with a "Base" suffix if the class is intended for use in public APIs.

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

小开

Also, if the abstract class has a few static members that will be used, the 'Base' can get ugly.

小开

Sometimes Base is still necessary, especially when you provide both a concrete class and an abstract class for someone to extend to create a concrete implementation.
e.g. Controller and ControllerBase (actually Controller is also abstract, but provides signifigantly more functionality than ControllerBase)

Base suffix is ugly when programming against an interface, so I think the Microsoft guideline not to use it applies when the abstract class is predominantly used like an interface. Probably what they mean by Public API.

The point is that there are cases where there is no better alternative to using the Base suffix.

小开

I understand the inclination to avoid a Base-Suffix, but I also understand the need for some Suffix. Now, a Comment of this article suggests using "Type" as a Suffix as second choice to not using any. I believe this to be confusing, but the Idea that "such a non-committal word would tend to indicate that it’s a non-committed class" stuck with me.

As an Alternative: I'd prefer using "Kind" as a suffix to state the object as “of or belonging to a specified race or family” (Wiktionary: -kind).

Example: DataProvider and ReflectiveDataProvider are both DataProviderKind

Inspired by Biology where e.g. "canis lupus" belongs to the family "Canoidea", which very roughly translates to "dog-ish".

小开

Microsoft states, at:

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

✓ CONSIDER ending the name of derived classes with the name of the base class. This is very readable and explains the relationship clearly. Some examples of this in code are: ArgumentOutOfRangeException, which is a kind of Exception, and SerializableAttribute, which is a kind of Attribute. However, it is important to use reasonable judgment in applying this guideline; for example, the Button class is a kind of Control event, although Control doesn’t appear in its name.

Generally speaking, this implicitly rules out using "Base" in the name.


提交答案