替换 API/类的命名约定答案

【问题标题】：Naming conventions for replacement APIs / classes替换 API/类的命名约定
【发布时间】：2009-01-22 20:57:13
【问题描述】：

对于正在逐步取代执行相同功能/担任相同角色的旧版本的 API 或类，您是否有命名约定？

例如Windows 通过在函数末尾添加“Ex”来做到这一点：

ShellExecute // old
ShellExecuteEx // new

你更喜欢什么，你的理由是什么？

附加2、V2、New、NowInStereo？
将旧 API 从 Something 一次性重命名为 SomethingOld 并将 Something 用于新内容？当涉及到版本控制时，这个选项让我很担心，但它似乎也最不可能在未来被V3 或ReallyNew 问题所困扰。
编造一个完全不同的名称可能不太准确地描述功能，但至少是不同的。

【问题讨论】：

【解决方案1】：

很多时候，您可以通过更改包名而不是类名本身来摆脱困境。

【讨论】：

【解决方案2】：

如果新类执行与旧类相同的功能，我将删除旧类并用同名的新类替换它。如果需要，我仍然可以在版本控制中查阅旧版本。

【讨论】：

我认为问题作者可能指的是需要向现有 API 函数添加新参数。在这种情况下，旧客户端将使用没有新参数的 API，因此如果不更新所有客户端就无法轻松替换它。有时您无法控制客户端。

【解决方案3】：

为什么要改变它？接口就是它们的契约，你为什么要在一切都使用它之后破坏接口。

编辑：抱歉让您的评论搞砸了 Josh...

我认为，如果您在创建界面时遇到了麻烦，您需要尽一切努力对其进行维护。你之前评论的时候在想什么样的错误选择？

【讨论】：

【解决方案4】：

仅当函数的参数因函数的新要求而发生更改时，您才需要创建一个新函数。

API 的最佳命名约定是 API 用户所期望的。如果 API 仅在 Windows 上使用，则添加 Ex（或 Ex2 用于下一个版本）可能是合适的。我不知道其他平台上的其他约定。此外，您的编程语言可能有扩展 API 方法的约定。

如果您使用面向对象的语言并且这是一个对象方法，则不必更改名称，因为您可以拥有具有相同名称和不同签名的方法。但是，提供一个新名称以让用户知道您希望他们迁移到新方法可能仍然有意义。

【讨论】：