关于接口设计的一点看法

　　花了几天时间，我完成了一个静态库。昨天我决定把提供三个接口给应用程序调用，这三个接口其实有着业务流程上的顺序关系，即应用程序必须按照这样的调用顺序：A－>B->C。我之所以提供三个接口，而不是抽象为一个，那是因为有些应用程序只需要执行到B这一步就可以满足需求了，而大部分应用程序则需要执行到C这一步才能完成其功能；提供了三个API，让应用程序的选择更加灵活，这是第一个原因；第二个原因，是因为我觉得如果只提供一个API，那么需要传入的用来保存上下文的参数将会是比较多的，大概有五到六个，对于我来说，我还是倾向于喜欢简单的接口。这是我昨天的想法。

　　然而今天我的想法改变了。我发现自己在应用程序上调用这三个API，每次都需要从A开始调用，然后B，然后C(有些不需要执行到C，但是执行了C也无妨)。我自己都有点烦了。于是我试着想象自己是一个对这个业务流程一无所知的用户，需要调用A->B->C这样的顺序，那么我需要提供给他们一个文档，把接口描述清楚，然后我要给他们描述业务逻辑，甚至，需要具体地说明一些细节。这实在是太麻烦了，所以今天我决定改一改静态库，我只提供一个API，这个API封装了整个流程，虽然参数多了点，有五个，但是只需要调用一个API就可以了，如果你的程序只需要执行到B这一步，那么，有三个参数你直接传入NULL指针就可以了，并无影响。于是我改了，然后重新写了AP，发现我这个想法是对的，最起码我不用再厌烦了。

　　接口的设计其实是很讲究的。如果你设计的接口需要用户了解很多他们本不该了解的，那么你的接口就设计得太复杂了，用户会抱怨，会反感。相反，如果你的接口设计得够简单，是一个好的黑盒子，他们不用对你的东西下更多的功夫，只需要轻轻地一个调用，就帮助他们完成了功能，他们也许会感谢你真的帮了大忙。但是，凡事也没有绝对，如果灵活性占据重要地位，那么也许你该考虑换换思路了。

　　呵呵，我想，我应该是对的。