C#类命名约定：是基类还是基于类还是抽象类

Posted 2023-02-22

【中文标题】C#类命名约定：是基类还是基于类还是抽象类

【英文标题】：C# Class naming convention: Is it BaseClass or ClassBase or AbstractClass

【发布时间】：2010-10-24 00:46:35

【问题描述】：

命名基类的推荐方法是什么？是在类型名称前加上“Base”还是“Abstract”，还是只在其后加“Base”？

考虑以下几点：

类型：ViewModel 例如MainViewModel，ReportViewModel

基类：BaseViewModel 或 ViewModelBase 或 AbstractViewModel

同时考虑：

类型：Product 例如虚拟产品，过期产品

基类：BaseProduct 或 ProductBase 或 AbstractProduct

你觉得哪个更标准？

class Entity : EntityBase

或

class Entity : BaseEntity

【问题讨论】：

另见Naming conventions for abstract classes

Using "Base" in a Class Name的可能重复

【参考方案1】：

Framework 中有带有 Base 后缀的示例，例如System.Configuration.Provider.ProviderBase, System.Web.SessionState.SessionStateStoreProviderBase.

但绝不是框架中的所有抽象基类都遵循这个约定（例如System.Data.Common.DbParameter、System.Data.Common.DbCommand）。

就我个人而言，我会避免使用后缀除非我想强调它是一个抽象类这一事实，并且认为否则该类的用户可能希望该名称表示一个具体的实现。

【讨论】：

"Avoid 使用 Base 后缀命名基类，如果该类旨在用于公共 API。"框架设计指南，第 174 页

【参考方案2】：

我认为这是一个选择问题。我想说，如果您要创建很多基类，那么最好始终使用 BaseClassname，因为这样您总是可以通过键入 Base 并获得其余帮助来找出可以开始使用的基类智能感知。如果你有 20 个 Base 类并且你添加 Base 作为后缀，你忘记了基类的名称是什么？您想先从 VS 创建一个类图并找出可用的基类吗？ 当只有一两个类时，可以将它们命名为 ClassBase。

GetItems 和 ItemsGet 函数之间的决定也是如此。我会说至少为了可读性 - 去 GetItems。遵守约定:)

【讨论】：

'Base' 类是 OO hack，请参阅 Paul's comment。它们通常很有帮助，有时甚至是必要的，但它们仍然是一个黑客。如果您觉得需要查找所有可用的基类，那是为什么呢？他们分享了什么让您需要一起看到他们？答案可以帮助您找到更好的命名方式。

@Abhishek：与GetItems 的类比是行不通的——“Get”只是一个动词，因此只能作为前缀在英语语法上有意义，而“Base”既可用作形容词（前缀）或名词（后缀）。

@Iain：人们在类名中使用“Base”的原因是不能找到所有的基类——基本原理更接近相反。这使得许多相关类的基类从它们中脱颖而出，就像“I”前缀旨在将接口与采用它的类区分开来一样。我已经看到当基类本身不起作用时最常使用“Base”前缀/后缀——按预期用途抽象，而不考虑强制执行的abstract。

@SlippD.Thompson 是的，“找到所有课程”是对 Abhishek 的回应。我回复了保罗的回答。

【参考方案3】：

在命名事物时，请始终考虑按字母顺序排列。我真的不喜欢查看 SQL 服务器，并且每个存储过程都被命名为 usp[something]。同样，不要过度使用 Get 和 Set 作为函数的前导名称。考虑将它们命名为 ItemsGet 或 OrderPlace，而不是 GetItems 或 PlaceOrder。

所以，一般来说，ClassnameBase / EntityBase 会是更好的选择。

【讨论】：

不同意；可读性。 GetItems 比 ItemsGet 更有意义。

不同意...与上述相同的原因..但无法投反对票... :(

与其他 cmets 相反，marcc 没有建议像 itemgsGet() 这样的东西。他写了 items()。

听起来太像您依赖 IDE 向您展示您正在寻找的内容，而不是了解您的代码。如果您的 IDE 不进行模糊名称匹配来帮助您找到所需内容，这听起来也像是 IDE 问题。这似乎更像是一种 IDE hack，而不是一种有用的编码实践。您的代码可能比您的 IDE 寿命更长，而新的 IDE 或版本功能可能会使它变得无用。

【参考方案4】：

如果您在谈论虚拟基类，Microsoft 的标准是 ClassnameBase（如 CollectionBase。）

【参考方案5】：

BaseEntity 看起来很像驼峰式案例 - strName、bseEntity。我会选择 EntityBase，因为它首先定义了主题，这将帮助您更快地识别它的功能。

【讨论】：

您说的是匈牙利符号，而不是驼峰式。匈牙利符号恰好是驼峰式，但它们是完全不同的东西。

【参考方案6】：

就个人而言，我建议完全不要添加词库。您永远不知道何时必须更改代码，它不再是基础对象。话虽如此，我们过去也这样做过，我们在前面加上了 Base 这个词。它似乎流动得更好。

【参考方案7】：

我们使用 BaseEntity，但我认为这是您自己的偏好。我经常看到另一个。

只要在您的上下文中保持一致，无论是您的项目、命名空间还是您的团队（如果可能）。恕我直言，不同的约定比糟糕的约定更糟糕。

【参考方案8】：

以上都不是。考虑你的基类提供什么目的；把它命名为。例如，汽车和自行车的基类可以是 Vehicle。

如果您创建基类只是为了拥有一个类的基类，并且没有其他目的或理由，那么您可能做错了什么。

【讨论】：

并非总是如此，您会在框架中找到许多 Base* 类。 CollectionBase，DictionaryBase ....等

好点现实世界的对象应该完全适合工件。公地的抽象应该像 Vehicle 一样基于，细节必须落后，但也要准确。

值得注意的是，.NET Framework 中带有“Base”后缀的某些类在 1.0 版之前命名，Microsoft 不再遵循这些约定......但它们无法更改名称现在。 Microsoft 的框架设计指南书第 6.2 节（涵盖基类）特别建议不要使用“Base”后缀。

我在许多公司看到的在许多 OO 语言中最常使用的做法是，“Base”指定仅用于继承的基类，而不是直接使用.在您的示例中，名为“Vehicle”的类听起来像是可以使用和“驱动”的东西——它声称自己是车辆。但是，如果基类被命名为“Vehicle Parts”或“Vehicle Essentials”或“Vehicle Kit”——我们知道它不是直接可用的东西，而是各种车辆的基础。

正如 Warren 所提到的，Microsoft 框架设计指南书，第 6.2 节关于基类：msdn.microsoft.com/en-us/library/ms229003(v=vs.110).aspx 他们说要避免使用 Base 后缀：“避免使用“Base”后缀命名基类，如果类旨在用于公共 API。”