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

Question

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

我需要创建同一个类的第二个版本,其中包括错误修复.我以前见过这样的情况,但我看到的命名总是增量Eg MyClass2, MyClass3.

这些情况可能非常罕见,但我想知道是否有更好的方法来命名这些"版本化"类.我想象一个解决方案,它会随着时间的推移而增长,并且具有这些类型的多个类,这些类可能会让人感到非常困惑,尤其是对于库而 我想象自己不得不之间挑选MyClass,MyClassV2,MyClassV3等.

Answer 1

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

标准的.NET命名约定是用增量的编号,如Class,Class2,Class3,等.这是来自于COM接口,专为正是您所描述的用例的命名约定.例如,IHTMLDocument界面目前有8个版本,IHTMLDocument从上到下IHTMLDocument8.

由Cwalina和Abrams撰写的最初的框架设计指南书明确推荐了这种做法,作者有这样的说法:

不要使用数字后缀来表示已有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 中添加对特定功能的支持,那么最好使用对该特定功能的引用来命名新类/接口.

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

Answer 2

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

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

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