API应该采用正确的调用顺序，还是应该验证假设？

Question

我有2个api调用来实现，让我们称之为“ShouldDoSomething”和“DoSomething”。第一个是测试是否需要采取特定操作而另一个实际采取该操作。当然，如果测试返回true，则仅采取行动是必要的或有效的。有些情况下需要进行测试而不实际采取行动，因此两者都是必要的。

如果动作调用内部运行测试并且如果不需要则成为无操作，或者实现是否应该在测试已经返回true的情况下才会调用它？验证假设似乎更简单，更安全，但是'action'调用有3个可能的返回状态而不是2个（成功，失败，不需要）。另一种方法是使测试成为断言并在不必要地调用操作时中止。 （这是在C中，所以异常并不是一个好主意）

但它归结为一个选择 - 更简单的api调用或更少的api调用？

Answer 1

我认为最好选择：

  

另一种方法是制作   测试一个断言并在中止时中止   行动被不必要地召唤。

例如，如果调用“DoSomething”并且“ShouldDoSomething”告诉您不应该执行该特定操作，那么“DoSomething应该在不执行任何操作的情况下中止。”您是否真的需要向客户端公开“ShouldDoSomething”，如果只测试是否应该调用“DoSomething”？

我认为这也取决于将要改变的内容。如果不恰当地打电话会不会致命？如果是这样，我认为你应该把断言放进去。如果它没有任何意义，那么它就没关系了。

我会说更安全是要走的路。

希望这有帮助。

Answer 2

根据您认为对于预期用例最干净的选择策略。清楚而仔细地记录下来。像这样的API决策最重要的是文档，而不是选择约定的具体细节。

如果您决定使用第一个选项，您是否真的需要添加“不需要”的返回状态，或者如果不需要操作，它是否只是表示“成功”？除非有必要，否则不要增加复杂性。

Answer 3

Stephen Canon对于一致性和文档是正确的。

就个人而言，我倾向于试图保护他们自己，除非这是一个严重的性能惩罚。在大多数情况下，我倾向于从DoSomething内部检查ShouldDoSomething，如果不需要DoSomething则返回错误。这表明用户存在​​逻辑错误，并且比让它们爆炸或者处于无效状态（可能难以调试线路）的情况要好得多。

Answer 4

最简单的API（从用户角度来看）将具有函数DoSomethingIfNeeded()，并让您处理条件。为什么要打扰用户？

最不友好的用户界面是：“现在调用其中一个函数！不，不是那个！”。