命名约定：如何命名相同class的不同版本？
Naming convention: How to name a different version of the same class?
我有一个 class MyClass 在实现中有一个错误。 class 是库的一部分，所以我无法更改 class 的实现，因为它会默默地改变现有客户端的行为（在这种情况下可能依赖于错误的客户端：请参阅示例 (https://connect.microsoft.com/VisualStudio/feedback/details/790160/httpclient-throws-operationcanceledexception-insead-of-timeoutexception))
我需要创建相同 class 的第二个版本，其中包括错误修复。
我以前见过这样的情况，但我见过的命名总是递增的，例如 MyClass2、MyClass3。
这些情况可能很少见，但我想知道是否有更好的方法来命名这些 "versioned" classes。
我想象一个解决方案会随着时间的推移而增长，并且有多个 class 这些类型，这可能会让人非常困惑，尤其是对于一个图书馆来说。我想象自己必须在 MyClass、MyClassV2、MyClassV3 等
之间进行选择
我会将现有 class 的所有行为复制到一个新的，重命名原始的以表明 class 已过时，将新的重命名为之前的实际名称并将原始的（现在使用新名称）标记为 [Obsolete] 表示不应再使用它。因此，所有消费代码都会自动调用新行为。因此，具有正确行为的新 class 获得原始 class 的名称，例如，越野车获得版本号。
对于遗留代码，您可以执行相反的操作，使用新名称创建新的 class，并将旧代码标记为 Obsolete。我知道带有版本号的 SDK，其中最后一个数字表示 class 的最新版本，所有其他的都具有这样的属性以及文档中提到 class 的通知已被新版本取代。
I was wondering if there is a better way of naming these "versioned" classes.
"classes which fix bugs in other classes" 没有 .NET 命名约定。我会向您工作场所的其他开发人员提出建议，看看他们是否有任何关于此类事情的公司惯例。我认为一致性比实际名称更重要。
关于您的问题的旁注，我根本不会创建新的 class。我会用 DeprecatedAttribute 标记该方法并在相同的 class 中实现逻辑，公开一组新的 API 方法，这些方法已正确记录以说明它们在此处作为修复。您图书馆的客户可能已经熟悉 MyClass，这样做可以简化他们的使用，让他们每次都需要问自己 "which version of this should I use"。
我认为重复 class 名称会严重混淆其他人加班。您使用 c# 接口提取方法并实现不同的版本。
在理想情况下，新版本会引入额外的功能，同时仍然保持与 API 以前版本的 100% 向后兼容性。不幸的是，理想的世界仍然难以捉摸，而且并不总是能够保持完全的向后兼容性。在这种情况下，版本后缀是合适的模式。
标准的.NET命名约定是使用增量编号，如Class、Class2、Class3等。这来自COM接口的命名约定，设计正是您所描述的用例。例如，IHTMLDocument 界面目前有 8 个版本，从 IHTMLDocument 到 IHTMLDocument8。
Cwalina 和 Abrams 的 Framework Design Guidelines 原著明确推荐了这种做法，作者是这样说的：
DO use a numeric suffix to indicate a new version of the existing API, if the existing name of the API is the only name that makes sense (i.e., it is an industry standard), and adding any meaningful suffix (or changing the name) is not an appropriate option.
// 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 的新改进版本中，该后缀来自单词"extend." 然而，这并不能很好地扩展，导致函数后缀令人困惑 ExEx。我认为没有 ExExEx;每个人都不敢碰那些 API。 Framework Design Guidelines 明确推荐反对 这种做法，那些继续构建 .NET 的人已经吸取了教训：
DO NOT use the "Ex" (or similar) suffix for an identifier to distinguish it from an earlier version of the same 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 的新版本中添加对 特定 功能的支持，您最好参考该特定功能命名新 class/interface。
虽然以上内容几乎完全集中在 classes 和接口上，但相同的逻辑适用于可能在以后的修订中添加的 class 的任何成员函数。原始函数可以保留其原始名称，新添加的函数可以使用不同的名称来反映其迭代或添加的功能。
为清楚起见，如果发生这种情况，我使用 ClassV2. 这表示它是 class 的另一个版本。
我有一个 class MyClass 在实现中有一个错误。 class 是库的一部分，所以我无法更改 class 的实现，因为它会默默地改变现有客户端的行为（在这种情况下可能依赖于错误的客户端：请参阅示例 (https://connect.microsoft.com/VisualStudio/feedback/details/790160/httpclient-throws-operationcanceledexception-insead-of-timeoutexception))
我需要创建相同 class 的第二个版本，其中包括错误修复。
我以前见过这样的情况，但我见过的命名总是递增的，例如 MyClass2、MyClass3。
这些情况可能很少见，但我想知道是否有更好的方法来命名这些 "versioned" classes。
我想象一个解决方案会随着时间的推移而增长，并且有多个 class 这些类型，这可能会让人非常困惑，尤其是对于一个图书馆来说。我想象自己必须在 MyClass、MyClassV2、MyClassV3 等
我会将现有 class 的所有行为复制到一个新的，重命名原始的以表明 class 已过时，将新的重命名为之前的实际名称并将原始的（现在使用新名称）标记为 [Obsolete] 表示不应再使用它。因此，所有消费代码都会自动调用新行为。因此，具有正确行为的新 class 获得原始 class 的名称，例如，越野车获得版本号。
对于遗留代码，您可以执行相反的操作，使用新名称创建新的 class，并将旧代码标记为 Obsolete。我知道带有版本号的 SDK，其中最后一个数字表示 class 的最新版本，所有其他的都具有这样的属性以及文档中提到 class 的通知已被新版本取代。
I was wondering if there is a better way of naming these "versioned" classes.
"classes which fix bugs in other classes" 没有 .NET 命名约定。我会向您工作场所的其他开发人员提出建议，看看他们是否有任何关于此类事情的公司惯例。我认为一致性比实际名称更重要。
关于您的问题的旁注，我根本不会创建新的 class。我会用 DeprecatedAttribute 标记该方法并在相同的 class 中实现逻辑，公开一组新的 API 方法，这些方法已正确记录以说明它们在此处作为修复。您图书馆的客户可能已经熟悉 MyClass，这样做可以简化他们的使用，让他们每次都需要问自己 "which version of this should I use"。
我认为重复 class 名称会严重混淆其他人加班。您使用 c# 接口提取方法并实现不同的版本。
在理想情况下，新版本会引入额外的功能，同时仍然保持与 API 以前版本的 100% 向后兼容性。不幸的是，理想的世界仍然难以捉摸，而且并不总是能够保持完全的向后兼容性。在这种情况下，版本后缀是合适的模式。
标准的.NET命名约定是使用增量编号，如Class、Class2、Class3等。这来自COM接口的命名约定，设计正是您所描述的用例。例如，IHTMLDocument 界面目前有 8 个版本，从 IHTMLDocument 到 IHTMLDocument8。
Cwalina 和 Abrams 的 Framework Design Guidelines 原著明确推荐了这种做法，作者是这样说的：
DO use a numeric suffix to indicate a new version of the existing API, if the existing name of the API is the only name that makes sense (i.e., it is an industry standard), and adding any meaningful suffix (or changing the name) is not an appropriate option.
// 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 的新改进版本中，该后缀来自单词"extend." 然而，这并不能很好地扩展，导致函数后缀令人困惑 ExEx。我认为没有 ExExEx;每个人都不敢碰那些 API。 Framework Design Guidelines 明确推荐反对 这种做法，那些继续构建 .NET 的人已经吸取了教训：
DO NOT use the "Ex" (or similar) suffix for an identifier to distinguish it from an earlier version of the same 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 的新版本中添加对 特定 功能的支持，您最好参考该特定功能命名新 class/interface。
虽然以上内容几乎完全集中在 classes 和接口上，但相同的逻辑适用于可能在以后的修订中添加的 class 的任何成员函数。原始函数可以保留其原始名称，新添加的函数可以使用不同的名称来反映其迭代或添加的功能。
为清楚起见，如果发生这种情况，我使用 ClassV2. 这表示它是 class 的另一个版本。