blocks|key|3134920|text|我不记得有这样的指导方针。我相信你应该使用有意义的命名。有时，抽象类只被设计为向某些类提供公共功能(作为工具)，我认为这些类应该有后缀。但是，在某些情况下，您希望将其用作多态层次结构的基础，而它本身并不完整。在这些情况下，我建议像普通类一样命名。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3134921|如您所见，您可能不会声明一个接受ButtonBase作为参数的方法。它的设计目的是为子类提供最少的功能。但是，您可以将ConfigurationElement视为具有不同形式的实体，但它本身并不完整(因此它是抽象的)|offset|length|style|CODE|3134922|entityMap^0|0|1N|K|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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 <code>ConfigurationElement</code> as an entity that has different forms but it is not complete on itself (and hence it's abstract)

blocks|key|351034|text|在Framework+Design+Guidelines+p174状态下：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|351035|351036|+如果要在公共API中使用基类，则应避免使用带有"+base“后缀的API命名基类。|blockquote|style|BOLD|351037|351038|351039|还有：http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx|351040|entityMap|0|LINK|mutability|MUTABLE|url|http://www.amazon.co.uk/Framework-Design-Guidelines-Conventions-Libraries/dp/0321246756/ref=sr_1_2?ie=UTF8&qid=1231531546&sr=8-2|1|http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx^0|1|R|0|0|0|1|C|0|0|0|3|1T|1|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|-4|5|6|7|11|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|12|8|@$A|13|B|14|H|I]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|15|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|16|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|17|8|@]|9|@$A|18|B|19|1|1A]]|C|$]]|$1|N|3|-4|5|6|7|1B|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]|V|$5|Q|R|S|C|$T|W]]]]

In <a href="http://www.amazon.co.uk/Framework-Design-Guidelines-Conventions-Libraries/dp/0321246756/ref=sr_1_2?ie=UTF8&amp;qid=1231531546&amp;sr=8-2" rel="noreferrer">Framework Design Guidelines</a> p 174 states:

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

Also : <a href="http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx" rel="noreferrer">http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx</a>

blocks|key|3347871|text|此外，如果抽象类有一些将被使用的静态成员，“Base”可能会变得丑陋。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3347872|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|356218|text|有时Base仍然是必要的，特别是当你同时提供了一个具体的类和一个抽象的类供人扩展以创建一个具体的实现时。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|356219|例如控制器和ControllerBase+(实际上控制器也是抽象的，但提供了比ControllerBase多得多的功能)|356220|当使用接口编程时，基本后缀是丑陋的，所以我认为当抽象类主要像接口一样使用时，微软的指导方针是不使用它。也许这就是他们所说的公共API。|356221|重点是，在某些情况下，除了使用Base后缀之外，没有更好的替代方法。|356222|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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.

blocks|key|3135114|text|我理解避免使用Base-Suffix的倾向，但我也理解需要一些后缀。现在，一个评论of+this+article建议使用“类型”作为后缀，作为不使用任何后缀的第二选择。我认为这是令人困惑的，但“这样一个未提交的词往往会表明它是一个未提交的类”的想法让我印象深刻。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3135115|作为替代：我更喜欢使用“”作为后缀来表示对象为“属于或属于一个特定的种族或家族”(Wiktionary:+-kind)。|style|BOLD|3135116|示例：DataProvider和ReflectiveDataProvider都是DataProviderKind|CODE|3135117|灵感来自生物学，例如，“犬狼疮”属于“独木舟”家族，非常粗略地翻译为“狗样的”。|3135118|entityMap|0|LINK|mutability|MUTABLE|url|https://blogs.msdn.microsoft.com/kcwalina/2005/12/16/i-dont-like-the-base-suffix/|1|https://en.wiktionary.org/wiki/-kind^0|15|F|0|0|C|1C|15|H|1|0|0|1K|3|C|G|M|14|G|0|0|14|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|D|3|E|5|6|7|10|8|@$A|11|B|12|F|G]]|9|@$A|13|B|14|1|15]]|C|$]]|$1|H|3|I|5|6|7|16|8|@$A|17|B|18|F|G]|$A|19|B|1A|F|J]|$A|1B|B|1C|F|J]|$A|1D|B|1E|F|J]]|9|@]|C|$]]|$1|K|3|L|5|6|7|1F|8|@$A|1G|B|1H|F|G]]|9|@]|C|$]]|$1|M|3|-4|5|6|7|1I|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]|U|$5|P|Q|R|C|$S|V]]]]

I understand the inclination to avoid a Base-Suffix, but I also understand the need for some Suffix. Now, a Comment <a href="https://blogs.msdn.microsoft.com/kcwalina/2005/12/16/i-dont-like-the-base-suffix/" rel="nofollow noreferrer">of this article</a> 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” (<a href="https://en.wiktionary.org/wiki/-kind" rel="nofollow noreferrer">Wiktionary: -kind</a>). 

Example: <code>DataProvider</code> and <code>ReflectiveDataProvider</code> are both <code>DataProviderKind</code>

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

blocks|key|351148|text|微软声明，在：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351149|https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces|offset|length|351150|“按钮考虑以基类的名称结束派生类的名称。这非常易读，并且清楚地解释了关系。代码中的一些例子是:+ArgumentOutOfRangeException是一种异常，SerializableAttribute是一种属性。但是，在应用此准则时使用合理的判断是很重要的；例如，✓类是一种控件事件，尽管控件没有出现在其名称中。”|351151|一般来说，这隐含地排除了在名称中使用"Base“。|351152|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|2Y|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@$D|S|E|T|1|U]]|A|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|C]]]]

Microsoft states, at:

<a href="https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces</a>

"✓ 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.

I distinctly remember that, at one time, the guideline pushed by Microsoft was to add the &quot;Base&quot; suffix to an abstract class to obviate the fact that it was abstract. Hence, we have classes like <code>System.Web.Hosting.VirtualFileBase</code>, <code>System.Configuration.ConfigurationValidatorBase</code>, <code>System.Windows.Forms.ButtonBase</code>, and, of course, <code>System.Collections.CollectionBase</code>.
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:
<ul>
<li><code>System.DirectoryServices.ActiveDirectory.DirectoryServer</code>
</li>
<li><code>System.Configuration.ConfigurationElement</code>
</li>
<li><code>System.Drawing.Brush</code>
</li>
<li><code>System.Windows.Forms.CommonDialog</code>
</li>
</ul>
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 <a href="http://msdn.microsoft.com/en-us/library/ms229040.aspx" rel="nofollow noreferrer">Names of Classes, Structs, and Interfaces</a> on MSDN at <a href="http://msdn.microsoft.com/en-us/library/ms229042.aspx" rel="nofollow noreferrer">Design Guidelines for Developing Class Libraries</a>. Oddly, I can find no mention of the guideline to add &quot;Base&quot; 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. <a href="https://docs.microsoft.com/en-us/archive/blogs/kcwalina/i-dont-like-the-base-suffix" rel="nofollow noreferrer">Krzysztof Cwalina gripes about it in 2005.</a>

Naming conventions for abstract classes

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我清楚地记得，有一段时间，微软推动的指导方针是在抽象类中添加"Base“后缀，以消除它是抽象的事实。因此，我们有像System.Web.Hosting.VirtualFileBase、System.Configuration.ConfigurationValidatorBase、System.Windows.Forms...

问抽象类的命名约定
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问抽象类的命名约定EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问抽象类的命名约定
EN