严格API与容错API

假设这是1990年代初，您是James Gosling第一次实现String.substring(int，int)。当索引参数超出范围时应该发生什么情况？这些测试应该通过吗？还是扔？Public void testSubstring(){assertEquals("；class"；，"；superclass"；.substring(5，32))；assertEquals("；superclass"；，"；superclass"；.substring(-2，5))；assertEquals("；"；，"；superclass"；.substring(20，24))；assertEquals("；superclass"；，"；superclass"；)；.substring(10，0))；}。

在一个宽容的API中，这些测试都通过了。该实现将识别超出范围的索引并对其进行校正。容错API的好处：更容易针对其进行编码。如果您不知道对给定的参数使用什么，只需传递NULL，实现就会做一些合理的事情。

在严格的API中，禁止子字符串的参数超出范围，并且该方法抛出IllegalArgumentException。严格API的好处：更易于维护。通过限制有效输入的数量，可以减少需要维护和测试的行为。

更容易预测。将无效输入映射到行为是一种艺术形式。在本例中，substring(10，0)是否应该返回空字符串？还是超级班？呼叫者会期待什么呢？

出于可维护性的考虑，我几乎总是更喜欢严格的API。我喜欢把代码中的类看作是一块上好的瑞士手表中的齿轮。所有的东西都紧密地结合在一起，对输入和输出都有严格的限制。我可以满怀信心地重构，因为如果我在其中引入了问题，系统就不会工作。有了一个容错的API，我可以引入错误，直到很久以后才能发现它们。