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.
Since in Java, you need to mark an abstract class with the aptly named abstract keyword, I would not include it in the name. In C++, for example, the case is not so clear cut, but at least the compiler will tell you when you incorrectly used an abstract class.
Normally, there is no suffix/prefix used when naming abstract classes, unlike interfaces, which have the prefix "I". Just give your class a name that describes what it is for, in a short precise way.
There should be no need for a name with "Abstract" in business code. For framework code it is a good and helpful convention to have interface -> abstract -> default. As the interface defines the type that the other code will work on it should not have any additional identifying parts (like prepended "I").
Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With