Naming conventions for abstract classes

Question

I distinctly remember that, at one time, the guideline pushed by Microsoft was to add the "Base" suffix to an abstract class to obviate the fact that it was abstract. Hence, we have classes like System.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, System.Windows.Forms.ButtonBase, and, of course, System.Collections.CollectionBase.

But I've noticed that, of late, a lot of abstract classes in the Framework don't seem to be following this convention. For example, the following classes are all abstract but don't follow this convention:

• System.DirectoryServices.ActiveDirectory.DirectoryServer

• System.Configuration.ConfigurationElement

• System.Drawing.Brush

• System.Windows.Forms.CommonDialog

And that's just what I could drum up in a few seconds. So I went looking up what the official documentation had to say, to make sure I wasn't crazy. I found the Names of Classes, Structs, and Interfaces on MSDN at Design Guidelines for Developing Class Libraries. Oddly, I can find no mention of the guideline to add "Base" to the end of an abstract class's name. And the guidelines are no longer available for version 1.1 of the Framework.

So, am I losing it? Did this guideline ever exist? Has it just been abandoned without a word? Have I been creating long class names all by myself for the last two years for nothing?

Someone throw me a bone here.

Update I'm not crazy. The guideline existed. Krzysztof Cwalina gripes about it in 2005.

Answer 1

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)

Answer 2

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

Answer 3

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

Answer 4

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.