当我尝试重构我的功能以满足新的需求时，我不时会遇到一个关键问题：
我应该添加另一个具有默认值的变量吗？或者我应该只使用一个数组，我可以在不破坏 API 的情况下添加一个额外的变量？
问问题
321 次
6 回答
1
除非您需要支持灵活数量的变量，否则我认为最好明确标识每个参数。在大多数情况下，您可以添加具有不同签名的重载方法以支持额外参数，同时仍支持原始方法签名。如果您使用数组来传递变量，它只会让您的 API 用户感到困惑。显然，有一些输入适合数组（多边形中的点列表、您希望对其执行操作的帐户 ID 列表等），但如果它不是您合理期望的变量数组或列表，您应该将其作为单独的参数传递给方法。
于 2009-11-14T20:27:30.480 回答
1
就像编程中的许多问题一样，正确的答案是“视情况而定”。
以 Javascript/jQuery 为例，一个很好的经验法则是每次调用函数时是否需要该参数，或者它是否是可选的。例如，主 jQuery 函数本身需要一个表达式来确定操作将影响哪些元素：
jQuery(expresssion)
尝试将此参数作为数组的一部分传递是没有意义的，因为每次调用此函数时都需要它。
另一方面，许多 jQuery 插件需要几个可能是可选的杂项参数。按照惯例，这些是通过“选项”数组作为参数传递的。正如您所说，这提供了一个很好的接口，因为可以添加新参数而不影响现有 API。这也使 API 变得干净，因为用户可以忽略那些不适用的选项。
一般来说，当涉及多个参数时，将它们作为数组传递是一个很好的约定，因为它们中的许多肯定是可选的。这将有助于清理许多 WIN32 API，尽管在 C/C++ 中处理数组比在 Javascript 中更难。
于 2009-11-14T20:35:22.320 回答
0
你都不应该这样做。只需添加参数并更改所有调用者以提供正确的默认值。原因是具有默认值的参数只能在末尾，并且无法在参数列表中的任何位置添加任何需要的参数，而不会有误解的风险。
这些是灾难的关键步骤： 1. 添加一个或两个带有默认值的参数 2. 一些调用者将提供它，而一些调用者将依赖默认值。[半年过去了] 3. 添加一个必填参数（在他们之前） 4. 将所有调用者更改为接受必填参数 5. 接到电话，或其他会让您忘记更改部分实例的事件# 2 6. 现在你的程序编译完美，但是无效。
不幸的是，在函数调用语义中，我们通常没有机会按名称说出哪个值在哪里。
数组也不是一个合适的解决方案。数组应该用作类似对象的连接，在其上执行统一的活动。正如他们在这里所说，如果值得重构，那么现在就值得重构。
于 2009-12-29T14:24:47.757 回答
0
这取决于所使用的编程语言。
如果你有一个普通的 OO 语言，你应该使用一个可以轻松扩展的对象，如果你真的关心 API 的一致性。
如果这无关紧要，则可以选择更改方法签名并使用更多/不同的参数重载方法。
如果您的语言都不支持并且您希望 API 是二进制稳定的，请使用数组。
于 2009-11-14T20:30:24.437 回答
0
有几个必须考虑的因素。
- 函数在哪里使用？- 仅在您创建的代码中？一个地方还是几百个地方？维护现有代码所需完成的工作量很重要。请记住包括与当前可能正在使用您的函数的其他程序员进行通信所需的时间。
- 新参数有多重要？- 你想要求它被使用吗？如果它有一个默认值，该默认值是否会以任何微妙的方式破坏该函数的现有使用？
- 易于理解 - 有多少参数已经传递到函数中？数字越大，就越容易混淆和出错。Code Complete建议您将参数数量限制为 7 个或更少。如果您需要更多，您应该尝试将部分或全部相关参数抽象到一个对象中。
- 其他特殊考虑 - 您是否想针对任何特殊条件（例如代码速度或大小）优化您的工作？对于您的执行环境，是否有任何必须考虑的特殊注意事项？牢记您的项目目标，并确保您所做的任何设计选择都不会与它们背道而驰。
于 2009-11-14T20:31:40.737 回答
0
在他的书Code Complete中，Steve McConnell 规定一个函数的参数永远不能超过 7 个，甚至很少有那么多。他提出了令人信服的论点——唉，我无法从记忆中引用这些论点。
最近，清洁代码主张更少的论点。
因此，除非要传递的东西的数量非常少，否则它们应该在一个包络结构中传递。如果它们是同质的，则为数组。如果没有，那么应该为此目的构建一个合理的轻量级对象。
于 2009-11-14T20:38:46.340 回答