API设计之功能小而集中

小而集中的API经常更优于旨在解决所有问题的大API。更小的API意味着更小的内存空间和更短的构建时间。

小的API更容易学习。不会花大量时间学习API的系列特性，只需要查看API的特性是否在你的应用场景中是否适用。

当你收到用户发给你带各种建议的email时，你更倾向于为你的API添加特性。此时，如果没有确定一个建议对你API解决的核心问题有帮助，你应该抵御住立即去实现这个建议的诱惑。

大多任何API都可能会有许多或有或无的特性。其中一些特性使API更容易使用，并因此显得合理。其他的特性起初看起来像是一个好想法，但不是真正的核心特性，或者只是局限在一部分主要特性使用场景中。这些建议就应该丢弃，可能会使你的API处于凌乱状态而不是优化它。

例如，在Butterfly Persistence中，我曾经考虑自动事务ID生成。事务ID对于记录日志非常有帮助，可用于查看哪些操作归属于相同的事务。但是我目前还未实现这一特性，主要由于以下原因：

Butterfly Persistence的用户可能希望他的事务ID来组成更多的信息而不仅是API得到的信息：Server-ID, HTTP-session ID, User ID等等。因为Butterfly Persistence不知道事务ID是否用于桌面应用，服务端命令行应用，或者web应用，这怎么能在事务ID中包含这些信息，它只能包含一些像是机器IP地址和时间的素材。

当然我可以让Butterfly Persistence的使用者使用ITransactionIDGenerator的实现来补充这些信息。但在大多数情况下者对于用户来说，在Butterfly Persistence之外实现这一接口，而不用担心怎样使用ITransactionIDGenerator来获取服务ID, 用户ID, 会话ID等。