框架API设计相关的碎言

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

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

2- 造成框架的频繁而仓猝的升级， 难免又引入新的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？