抽象类的命名约定
我清楚地记得，曾经，微软推行的指导方针是在抽象类中添加“Base”后缀，以消除它是抽象的事实。 因此，我们有诸如 System.Web.Hosting.VirtualFileBase 、 System.Configuration.ConfigurationValidatorBase 、 System.Windows.Forms.ButtonBase 等类当然是System.Collections.CollectionBase。
但我注意到，最近框架中的许多抽象类似乎没有遵循这个约定。 例如，以下类都是抽象类，但不遵循此约定：
System.DirectoryServices.ActiveDirectory.DirectoryServerSystem.Configuration.ConfigurationElementSystem.Drawing.BrushSystem.Windows.Forms.CommonDialog
这就是我在几秒钟内就能鼓起的东西。 所以我去查找官方文档的内容，以确保我没有疯。 我在 MSDN 上找到了类、结构和接口的名称，网址为 < a href="http://msdn.microsoft.com/en-us/library/ms229042.aspx" rel="noreferrer">开发类库的设计指南。 奇怪的是，我找不到任何提及在抽象类名称末尾添加“Base”的指南。 该指南不再适用于框架 1.1 版本。
那么，我会失去它吗？ 这个指导方针曾经存在过吗？ 难道就这样一声不吭地被抛弃了吗？ 过去两年我自己创建长类名是否毫无意义？
有人在这里扔了我一根骨头。
更新 我没疯。 指导方针是存在的。 Krzysztof Cwalina 在 2005 年对此表示抱怨.
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.DirectoryServerSystem.Configuration.ConfigurationElementSystem.Drawing.BrushSystem.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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
在 框架设计指南第 174 页指出：
另：http://blogs.msdn.com/kcwalina/archive /2005/12/16/BaseSuffix.aspx
In Framework Design Guidelines p 174 states:
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.
我不记得有这样的指导方针。 我相信您应该使用有意义的命名。 有时抽象类只是为了给某些类（作为工具）提供通用功能而设计的，我认为应该带有后缀。 但是，在某些情况下，您希望将它用作多态层次结构的基础，但它本身并不完整。 在这些情况下，我建议像普通类一样命名。
如您所见，您可能不会声明接受 ButtonBase 作为参数的方法。 它旨在为子类提供最少的功能。 但是，您可以将
ConfigurationElement视为具有不同形式的实体，但它本身并不完整（因此它是抽象的）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
ConfigurationElementas an entity that has different forms but it is not complete on itself (and hence it's abstract)有时 Base 仍然是必要的，特别是当您同时提供具体类和抽象类供某人扩展以创建具体实现时。
例如控制器和ControllerBase
（实际上 Controller 也是抽象的，但提供了比 ControllerBase 更多的功能）
在针对接口进行编程时，Base 后缀很难看，所以我认为当抽象类主要像接口一样使用时，不使用它的 Microsoft 指南适用。 可能他们所说的公共 API 是什么意思。
关键是，在某些情况下，没有比使用 Base 后缀更好的替代方法。
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.
微软声明，在：
https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces
一般来说，这隐含地排除了在名称中使用“Base”的可能性。
Microsoft states, at:
https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces
Generally speaking, this implicitly rules out using "Base" in the name.
我理解避免使用基本后缀的倾向，但我也理解需要一些后缀。 现在，一条评论 本文建议使用“Type”作为后缀，作为不使用任何后缀的第二选择。 我认为这令人困惑，但“这样一个不承诺的词往往表明它是一个不承诺的类”的想法一直困扰着我。
作为替代方案：我更喜欢使用“Kind”作为后缀来声明该对象“属于或属于指定的种族或家庭”（维基词典：-kind）。
示例：
DataProvider和ReflectiveDataProvider都是DataProviderKind受生物学启发，其中“canis lupus”属于“Canoidea”家族，其翻译非常粗略到“狗式”。
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:
DataProviderandReflectiveDataProviderare bothDataProviderKindInspired by Biology where e.g. "canis lupus" belongs to the family "Canoidea", which very roughly translates to "dog-ish".