严格API与容错API

2020-10-29 02:43:40

假设这是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,我可以引入错误,直到很久以后才能发现它们。