新书到手

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

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

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

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

—— 记于百度空间

发表评论

电子邮件地址不会被公开。 必填项已用*标注