这是一个样式问题，在公共SDK的上下文中，由于向后兼容性要求，无法删除方法。
我在某些地方看到过，当添加新版本的方法时，它会具有相同的名称，但带有一些数字前缀，例如
void doTheThing2(...) {...};
乍一看，这很丑陋，而且显然没有做任何事情来传达方法的实际差异。另一方面，我发现在名称中该方法的“版本2”中捕获语义变化通常更加难看，有时甚至是不可能的。例如，
boolean doTheThingButReturnResultCode(...) {...};
天哪，如果您有该方法的第3版，那该怎么办？
很明显，我在用Java编写代码，但是这个问题并非特定于Java。而且我意识到这里没有客观答案，但是希望能以理性的方式获得一些意见。
答案 0 :(得分：1)
我会建议您不要这样做，但这不是无效的。我认为您非常正确的想法是在相当长的一段时间内在公共API中保持方法的向后兼容性，并明确标明弃用期。
后缀的一个问题是，新方法最终会（例如在1-2个主要API版本之后）成为使用的主要方法。但这破坏了正在工作的程序员的流程-您仍然得到遗留在方法后面的后缀。即使在此之前，method()和method2()之间的含义通常也不是很明确的约定。
由于英语是一种富含同义词的语言，因此我已经看到它们在方法级别上优于版本后缀。通常这很少是为了清楚和简单而牺牲的。例如，addItem() (deprecated)可能会变成storeItem()。当可以在API中的多个位置遵循新的命名约定时，这特别好用。然后addWidget()和addWudget()变成storeWidget()和storeWudget()。
您可以看到这种同义词方法存在于Java和Python API本身中-它们很少使用数字后缀。也许String.subSequence()方法可以视为String.substring()的版本2。
数字后缀的另一个问题是不清楚数字是什么版本。它是该方法的版本吗？ API的？一年？ Java版本？ API主版本可能最有意义，但是如果不添加更长的后缀（如addItemJava2()或addItemV2()），很难始终如一地提供此上下文。在主要API版本更改后，使用孤立的数字后缀也变得不直观。我现在应该使用addItemv3()，它是API版本5吗？
我已经看到数字后缀在接口和类名中的使用更为有效。也许是因为它们在方法名称中更常见的是名词，而不是动词。拥有CarModel2比拥有drive2()更有意义。也许因为它们是接口，所以一致的上下文更容易在API的更广泛的表面上使用，因此API的用户也会发现它。
关于样式，其中一些可能是主观的，但是这些是设计上要考虑的压力。