命名约定：如何命名同一类的不同版本？答案

【问题标题】：Naming convention: How to name a different version of the same class?命名约定：如何命名同一类的不同版本？
【发布时间】：2016-03-03 15:39:24
【问题描述】：

我有一个类MyClass，它在实现中有一个错误。该类是库的一部分，因此我无法更改该类的实现，因为它会默默地改变现有客户端的行为（在这种情况下可能依赖该错误的客户端：例如参见 (https://connect.microsoft.com/VisualStudio/feedback/details/790160/httpclient-throws-operationcanceledexception-insead-of-timeoutexception)）

我需要创建包含错误修复的同一类的第二个版本。我以前见过这样的情况，但我见过的命名总是递增的，例如MyClass2、MyClass3。

这些情况可能很少见，但是我想知道是否有更好的方法来命名这些“版本化”类。我想象一个解决方案会随着时间的推移而增长，并且具有这些类型的多个类，这可能会让人感到非常困惑，尤其是对于图书馆而言。我想自己必须在MyClass、MyClassV2、MyClassV3 等之间做出选择。

【问题讨论】：

不确定是否存在为此的命名约定，但我会使用 MyClassVX 并将以前的标记为已过时。
有人可能会说这个问题主要是基于意见的，就像所有关于命名约定的问题一样。 programmers.stackexchange.com 可能会更好地接收您的问题？

标签： c# .net naming-conventions

【解决方案1】：

在理想情况下，新版本将引入额外的功能，同时仍保持 100% 向后兼容 API 的先前版本。不幸的是，理想的世界仍然难以捉摸，并且并不总是能够保持完全的向后兼容性。在这种情况下，版本化后缀是合适的模式。

标准的 .NET 命名约定是使用递增编号，例如 Class、Class2、Class3 等。这来自 COM 接口的命名约定，专为您的用例而设计描述。比如IHTMLDocument接口目前有8个版本，从IHTMLDocument到IHTMLDocument8。

Cwalina 和 Abrams 的 Framework Design Guidelines 原著明确推荐了这种做法，作者是这样说的：

请使用数字后缀来表示现有 API 的新版本，如果 API 的现有名称是唯一有意义的名称（即，它是行业标准），并且添加任何有意义的后缀（或更改名称）不是合适的选择。
// old API
[Obsolete("This type is obsolete. Please use the new version of the same class, X509Certificate2."]
public class X509Certificate  { ... }

// new API
public class X509Certificate2 { ... }

最初的 Windows 团队所遵循的旧惯例是将后缀 Ex 添加到 API 的新改进版本中，该后缀来自“扩展”一词。但是，这不能很好地扩展，导致函数后缀为 ExEx 令人困惑。我认为没有ExExEx；每个人都害怕接触那些 API。 框架设计指南明确反对这种做法，那些继续构建 .NET 的人已经吸取了教训：

请勿使用“Ex”（或类似）后缀作为标识符，以将其与同一 API 的早期版本区分开来。

[Obsolete("This type is obsolete. ..."]
public class Car  { ... }

// new API
public class CarEx      { ... }     // the wrong way
public class CarNew     { ... }     // the wrong way
public class Car2       { ... }     // the right way
public class Automobile { ... }     // the right way

显然，正如他们最后的代码示例所暗示的那样，如果您要在新版本的 API 中添加对特定功能的支持，最好使用引用来命名新类/接口到那个特定的功能。

虽然上面几乎只关注类和接口，但同样的逻辑也适用于该类的任何成员函数，这些函数可能会在以后的版本中添加。原始函数可以保留其原始名称，而新添加的函数具有不同的名称，以反映其迭代或添加的功能。

【讨论】：

赞成发布设计指南和突出约定。虽然弃用方法也是我的首选解决方案，但在我遇到的极端情况下，这种特殊的解决方案是必要的。

【解决方案2】：

我想知道是否有更好的方法来命名这些“版本化”类。

对于“修复其他类中的错误的类”没有 .NET 命名约定。我会向您工作场所的其他开发人员提供建议，看看他们是否有任何公司惯例。我认为一致性比实际名称更重要。

顺便说一句，我根本不会创建新课程。我会用DeprecatedAttribute 标记该方法并在同一个类中实现逻辑，公开一组新的API 方法，这些方法已正确记录以说明它们在此处作为修复。您图书馆的客户可能已经熟悉MyClass，这样做可以方便他们的使用，让他们每次都需要问自己“我应该使用哪个版本”。

【讨论】：

【解决方案3】：

我会将现有类的所有行为复制到一个新类中，重命名原始类以表明该类已过时，将新类重命名为之前的实际名称并标记原始类（使用新名称现在）作为[Obsolete] 表示不应再使用它。因此，所有消费代码都会自动调用新行为。因此，具有正确行为的新类将获得原始类的名称，例如，错误的类会获得版本号。

对于遗留代码，您可以做相反的事情，使用新名称创建一个新类并将旧类标记为Obsolete。我知道带有版本号的 SDK，其中最后一个数字表示该类的最新版本，并且所有其他人都具有这样的属性以及文档中提到该类已被新版本取代的通知。

【讨论】：

【解决方案4】：

我认为重复类名会严重混淆其他人加班。您使用 c# 接口提取方法并实现不同的版本。

【讨论】：

虽然并不总是适用，但这是适用时的解决方案。这应该向上移动

【解决方案5】：

为了清楚起见，如果发生这种情况，我使用ClassV2. 这表示它是该类的另一个版本。

【讨论】：