抽象类的命名约定
我清楚地记得，有一次，微软提出的指导方针是在抽象类中增加“基本”后缀，以避免它是抽象的。 因此，我们有类似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 开发类库的devise指南中find了类，结构和接口的名称 。 奇怪的是，我没有提到在抽象类的名字末尾添加“Base”的指南。 该指南已不再适用于框架1.1版本。
那么，我输了吗？ 这个指导方针是否存在？ 它是否被一言不发放弃了？ 在过去的两年里，我自己一直创造了很长的名字吗？
有人在这里扔骨头。
更新我并不疯狂。 指南存在。 Krzysztof Cwalina在2005年抱怨。
框架devise指南第174页指出：
如果该类用于公共API，则避免使用“基本”后缀命名基类。
另外： http : //blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx
另外，如果抽象类有一些静态成员将被使用，那么“Base”会变得很难看。
我不记得这样的指导方针。 我相信你应该使用有意义的命名。 有时抽象类只是为了给一些类（作为一个工具）提供通用的function，我认为它应该有后缀。 但是，在某些情况下，您希望将其用作多态性层次结构的基础，因为它本身并不完整。 在这种情况下，我build议像普通class级一样命名。
正如你看到的，你不会声明一个接受ButtonBase作为参数的方法。 它旨在为子类提供最less的function。 但是，您可以将ConfigurationElement视为具有不同forms的实体，但它本身并不完整（因此是抽象的）
有时Base还是有必要的，特别是当你提供一个具体类和一个抽象类来扩展某个特定的实现时。
例如Controller和ControllerBase（实际上Controller也是抽象的，但是提供了比ControllerBase更多的function）
在对接口进行编程时，基本后缀是丑陋的，所以我认为微软的指导原则并不适用于抽象类主要用于接口的情况。 公共API可能意味着什么。
重点是有些情况下没有更好的select使用基本后缀。
