java - 方法 : is it a valid style? 的数字后缀(例如 myMethod2())

Question

这是一个风格问题，并且在公共(public) SDK 的上下文中，由于向后兼容性要求，无法删除方法。

我在某些地方看到，当添加方法的新版本时，它将具有相同的名称，但有一些数字前缀，例如，

void doTheThing2(...) {...};

乍一看，这非常丑陋，并且显然没有做任何事情来传达方法中的实际差异。另一方面，我发现它通常更难看，有时甚至不可能捕获名称中方法的“版本 2”中的语义变化。例如，

boolean doTheThingButReturnResultCode(...) {...};

如果你有该方法的版本 3，那又怎样呢？

显然我是用 Java 编码的，但这个问题并不是 Java 特有的。我意识到这里没有客观的答案，但希望得到一些理性的意见。

Answer 1

我会说这是不鼓励的，但并非无效。我认为您对于在公共(public) API 中的相当长一段时间内保持方法的向后兼容性有非常正确的想法，并明确公布了弃用期限。

后缀的一个问题是，新方法最终(比如在 1-2 个主要 API 版本之后)将成为主要使用的方法。然而，这破坏了程序员的工作流程——你会得到一个仍然附加在方法上的遗留后缀。即使在此之前，method() 和 method2() 之间的含义通常也没有明确的约定。

由于英语是一种富含同义词的语言，因此我发现这些同义词在方法级别上优于版本后缀。这通常不会牺牲清晰度和简单性。例如，addItem()(已弃用) 可能会变为 storeItem()。当 API 中的多个位置都可以遵循新的命名约定时，这种方法尤其有效。然后 addWidget() 和 addWudget() 变成 storeWidget() 和 storeWudget()。

您可以看到这种同义词方法存在于 Java 和 Python API 本身中 - 它们很少使用数字后缀。也许String.subSequence() 方法可以被视为String.substring() 的版本2。

数字后缀的另一个问题是不清楚该数字是什么版本。它是该方法的一个版本吗？ API 的？一年？ Java 版本？ API 主要版本可能最有意义，但如果不添加更长的后缀(如 addItemJava2() 或 addItemV2())，就很难一致地给出此上下文。在主要 API 版本更改后，使用孤立的数字后缀也会变得不直观。现在 API 版本为 5，我应该使用 addItemv3() 吗？

我发现数字后缀在接口(interface)和类名称中使用得更有效。也许这是因为它们通常是名词，而不是动词，而动词在方法名称中更常见。拥有 CarModel2 比 drive2() 更有意义。或者也许因为它们是接口(interface)，一致的上下文更容易在 API 的更广泛的表面上强加，因此 API 的用户会发现。

由于这涉及风格，其中一些可能是主观的，但这些是需要考虑的一些设计压力。