框架API设计相关的碎言

fujohnwang

2009-11-17


author: fujohnwang

框架的API设计,应该是一个从粗粒度到细粒度的精炼过程,而不能一开始就提供细粒度却没有考虑周全的API,这样的情况会:

造成框架使用者的窘迫, 当框架实现中存在bug的时候, 使用者将难以绕过这些bug而前行, 只能等待框架的bug fix版本的发布;

造成框架的频繁而仓猝的升级, 难免又引入新的bug;

从理性的角度来看, 框架的API设计, 开始之初, 应该是一种粗粒度的, 且功能限定几乎没有的形式。之后,可以根据使用者的反馈以及框架设计者本身的考虑,来进一步的细化或者暴露新的,但功能相似的API,也就是说,我们可以在之后鼓励使用者使用新的API,而尽量少用旧有的API, 这样的好处就是, 当新的API有考虑不周全的时候, 使用者依然可以转而求助于旧的,但功能几乎没有限定的API, 使得使用者不用心急火燎的等待框架新版本的发布, 与此同时,框架本身可能因为开发进度无法及时发布。

举例来说, 一个Web层的Action/Controller类的定义, 现在通常都是声明为一个简单的POJO, 框架设计者可能直接就规定死:在这些Action/Controller的定义中, 只能声明指定类型的参数。这样做的后果就是, 当框架指定的参数类型不能满足使用者需求的时候, 使用者会一筹莫展,因为, 除非框架升级,否则,他们无法获得更多的进展。

可是,如果框架设计者最初不是一上来就开始限定,而是,一开始先提供粗粒度的API要求,那么,上面的情况就可以绕得过去。不管什么参数类型,他们的数据来源最终都要通过ServletRequest输入,通过ServletResponse输出,那么,我们就可以对如下的Action/Controller的处理方法提供支持:

            public void actionMethod(ServletRequest requet, ServletResponse response);
            

然后,在这的基础上,再提供细粒度并且有效提炼的API支持:

            public void actionMethod(Type1 argument1, Type2 argument2, ...);
            

当框架提供的细粒度的API支持无法满足用户需求的时候,用户依然可以转而求助于最初的粗粒度的API,而不是眼巴巴的干等。

框架设计者提供细粒度的,精炼后的API当然是最初的目的,并且也是为了简化使用者的工作,但难免有考虑不周之处,所以,采取循序渐进, 留条后路的做法,很多情况下,对使用者来说,对框架设计来说,都会是受益的。使用者不用心急火燎的等待, 框架的设计和开发者也不用火烧屁股般紧急发布bugfix版本, good balance, isn’t it?


>>>>>> 更多阅读 <<<<<<

「为AI疯狂」星球上,扶墙老师正在和朋友们讨论有趣的AI话题,你要不要⼀起来呀?^-^
这里

  1. 不但有及时新鲜的AI资讯和深度探讨
  2. 还分享AI工具、产品方法和商业机会
  3. 更有体系化精品付费内容等着你,加入星球(https://t.zsxq.com/0dI3ZA0sL) 即可免费领取。(加入之后一定记得看置顶消息呀!)

知识星球二维码

存量的时代,省钱就是赚钱。
在增量的时代,省钱其实是亏钱。
避坑儿是省钱的一种形式,更是真正聪明人的选择!
弯路虽然也是路,但还是能少走就少走,背后都是高昂的试错成本。
订阅「福报」,少踩坑,少走弯路,多走一步,就是不一样的胜率!

订阅「福报Premium订阅」