近来因为一个项目，对 API 设计又捡了起来。没办法，因为人手紧张，不但设计了这套 API，而且还把它给实现了。在整个设计和实现的过程中，和经验丰富的征哥（他同时是这个项目的项目经理）多次沟通，和 API 的用户小罗同学也时有探讨。总体上来讲，最初的 API 涉及还算成功，到最后的实现结束，定好的函数原型基本上都没有动，只是由于和界面的交互有新的需求被发掘出来，所以增加了几个函数。

在目前的这个 API 层级上，我和征哥的分歧，而且几乎是唯一的分歧，在于一个很小的点上。那就是，API 要不要支持对所操作对象的批量操作。最初的实现我是以按照支持批量操作去做的，后来发现这样做，有两个缺点：1、调用者使用时，要填充一个结构链表，即使只操作一个元素，也至少要填充一个结构，而且要将其中的 next 域置 NULL，2、实现中，如果对一系列元素中的某个/些元素的处理失败了，返回错误的方法比较蹩脚，要求输入的结构中有放置错误码的域。反过来，这样做的优点则比较微小，仅仅是为了支持批量操作而为之，而事实上，如果暴露出的 API 仅支持单个元素的操作，然后在其上封装一个批量操作的函数是非常容易的事情。更何况，使用者操作单个元素要远比操作一系列元素常用到。最后和 API 用户小罗沟通后，还是把 API 修订为了只支持单个元素操作。我自忖这样的设计，在粒度层面应该是更为合适的，可惜设计这方面的书籍和资料我看得不多，不知道是不是有相关的指标是衡量这个的。

于是想起应该找点书补一补。到亚马逊上搜索，发现讲述大系统类型的设计类书籍好像挺多，到底该如何设计一个相对小一点的模块或者系统的书非常少（考虑我是不是该写一本，呵呵）。凭着感觉买了两本，一本是《软件框架设计的艺术》，另一本是《Linux 内核设计的艺术》，这后一本，距离我题中之意貌似已经有点远了。

说到亚马逊，又有点闲淡可扯一两句。亚马逊的 logo，下面是个从左到右黄色的箭头，不知为何，每次我看到都会联想到少儿不宜的男性人体器官，感觉那个标志更应该出现在兜售伟哥或者其他什么 enlarger 器具的地方。不知是不是我老人家自己的问题，总是想歪，有辱各位看官清听，恕罪则个。

—— 记于百度空间