扩展现有的 API：使用默认参数或包装函数？

Question

我有一个现有的方法（或一般的函数），我需要增加额外的功能，但我不想破坏代码中其他地方对该方法的任何使用。例子：

int foo::bar(int x)
{
 // a whole lot of code here
 return 2 * x + 4;
}

在代码库中被广泛使用。现在我需要将 4 设为参数，但任何已经调用 foo::bar 的代码仍应收到它所期望的内容。我是否应该扩展并重命名旧方法并将其包装成新方法，例如

int foo::extended_bar(int x, int y)
{
 // ...
 return 2 * x + y;
}

int foo::bar(int x)
{
 return extended_bar(x,4);
}

或者我应该在头文件中声明一个默认参数，例如

int bar(int x, int y=4);

并只是扩展功能

int foo::bar(int x, int y)
{
 // ...
 return 2 * x + y;
}

每个变体的优点和缺点是什么？

Answer 1

我通常使用一个 包装函数 （大多数时候通过重载）而不是默认参数。

原因是有两个层次 向后兼容性:

1. 拥有 源级 向后兼容性意味着您必须重新编译调用代码而不进行任何更改，因为新的函数签名与旧的函数签名兼容。两者都可以达到这个水平；默认值和包装/重载。

2. 更强的水平是 二进制级 向后兼容性，甚至无需重新编译即可工作，例如当您无权访问调用代码时。想象一下，您以二进制形式部署函数，例如在 DLL 中等。在这种情况下，签名必须完全相同才能使其正常工作，而默认值则不然 - 它们会破坏这种兼容性级别。

包装函数的另一个优点是 - 如果您的应用程序具有任何类型的日志记录 - 您可以在旧函数中转储警告，该函数将在未来版本中过时，并且建议使用新函数。

Answer 2

的时间越长我使用C ++，我喜欢默认函数的参数更少。我无法找出我不喜欢任何具体的原因，但我觉得，如果我使用他们，我几乎总是结束后删除它们。所以我的（主观）的投票去为新命名的功能 - 当然的名称可能是相同的旧的

Answer 3

我个人认为，隐含的行为是（一）所有罪恶的根源。

凡是要维护者混淆或呼叫者被调用应该具有很强的理由目标的身份，尤其是如果它是一个主要的API的一部分。

因此，我会强烈反对与默认操作选项争辩。

另外，我认为，如果某一功能可以用不同数量的参数调用，然后有一些本质上的不同功能的两个版本或他们正在做的太多了。这种区别大概应在名称，应该可能更有意义比“_extended”