问命名约定:如何命名同一类的不同版本？

EN

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

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

另外，关于你的问题，我根本不会创建一个新的类。我将用DeprecatedAttribute标记该方法，并在同一个类中实现逻辑，公开一组新的API方法，这些方法被正确地记录下来，以声明它们在这里是一个修复程序。您库的客户端可能已经熟悉了MyClass，这样做将简化对它们的使用，使它们每次都需要问自己“应该使用哪个版本”。

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

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

由Cwalina和Abrams撰写的最初的https://rads.stackoverflow.com/amzn/click/com/0321545613书明确推荐了这种做法，作者必须这样说：

DO使用数字后缀来指示现有API的新版本，如果该API的现有名称是唯一有意义的名称(即，它是行业标准)，那么添加任何有意义的后缀(或更改名称)都不是合适的选择。 //旧API过时(“此类型已过时。请使用同一类的新版本，X509Certificate2。”公共类X509Certificate {.} //新API公共类X509Certificate2 {.}

旧的惯例是将后缀Ex添加到API的新版本和改进版本中，这个版本来自于“扩展”一词。然而，这并不能很好地扩展，导致函数的后缀ExEx令人困惑。我不认为有一个ExExEx；每个人都害怕接触那些API。“框架设计指南”明确建议反对这种做法，那些已经学到经验教训的架构师.NET：

不使用"Ex“(或类似的)后缀作为标识符，以区别于同一API的早期版本。 过时(“这种类型过时了.”公共类Car {.} //新API公共类CarEx {.} //公共类CarNew {.} //公共类Car2 {.} //正确方式公共类汽车{.} //正确方式

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

虽然上面的内容几乎完全集中在类和接口上，但同样的逻辑也适用于可能在以后的修订版中添加的该类的任何成员函数。原始函数可以保留其原始名称，新添加的函数具有反映其迭代或添加功能的不同名称。

我会将现有类的所有行为复制到新类，重命名原始类以表示类已过时，将新类重命名为以前的实际名称，并将原始类(现在使用新名称)标记为[Obsolete]，指示不再使用它。因此，所有消耗代码都会自动调用新的行为。因此，具有正确行为的新类将获得原始类的名称，例如，buggy类获得版本号。

对于遗留代码，您可以执行相反的操作，使用新名称创建一个新类，并将旧类标记为Obsolete。我知道SDK有一个版本号，最后一个数字表示类的最新版本，所有其他类都有这样一个属性，同时在文档中有一个通知，其中提到类被一个新版本所取代。