API的非向后兼容性无论如何通常代表着一种比较差的设计
2016-10-19 14:53
246 查看
不管一个类库或者工具方法实现多么的好,如果无法做到向后兼容性,通常会给用户带来很大的升级成本,很多对此的依赖如果希望在后续的升级和维护期间使用该类库的其他新增特性或者好处,将不得不推迟升级亦或是被迫接受改变。
无论这个类库实现的多么完美或者流行,如果版本升级意味着大量API或者包名的变更,我认为很大程度上是因为设计者意识到从维护的角度来说,这个类库的实现非常的糟糕,以至于已经非常的难以维护下去了。
在开源的社区,做这种变更或者说犯这种错几乎不需要付出任何成本,所以很多的类库甚至非常流行的类库都有发生大版本间API的完全重构,如果是商业类库,除非有适配API,恐怕用户都跑光了。常见的类库有如下:
jackson:
1.x:org.codehaus.jackson
2.x:com.fasterxml.jackson
由此带来的是大量类路劲的变化,spring HttpMessageConverter针对1.x和2.x的分别实现;到了spring 4.x,MappingJacksonHttpMessageConverter又被spring给删除了。
dbcp:
1.x:
2.x:
apache.common.lang:
2.x:
3.x:
log4j :
1.x:
2.x:
common.pool
1.x:
2.x:
netty:
4.x:
3.x:
不过主流的容器和应用服务器以及数据库则做的好的多,比如tomcat/nginx/mysql/postgresql/rabbitmq。
无论这个类库实现的多么完美或者流行,如果版本升级意味着大量API或者包名的变更,我认为很大程度上是因为设计者意识到从维护的角度来说,这个类库的实现非常的糟糕,以至于已经非常的难以维护下去了。
在开源的社区,做这种变更或者说犯这种错几乎不需要付出任何成本,所以很多的类库甚至非常流行的类库都有发生大版本间API的完全重构,如果是商业类库,除非有适配API,恐怕用户都跑光了。常见的类库有如下:
jackson:
1.x:org.codehaus.jackson
2.x:com.fasterxml.jackson
由此带来的是大量类路劲的变化,spring HttpMessageConverter针对1.x和2.x的分别实现;到了spring 4.x,MappingJacksonHttpMessageConverter又被spring给删除了。
dbcp:
1.x:
2.x:
apache.common.lang:
2.x:
3.x:
log4j :
1.x:
2.x:
common.pool
1.x:
2.x:
netty:
4.x:
3.x:
不过主流的容器和应用服务器以及数据库则做的好的多,比如tomcat/nginx/mysql/postgresql/rabbitmq。
相关文章推荐
- 为什么MVC不是一种设计模式? ---比较Backbone和Ext4.x在MVC实现上的差异
- atitit.跨语言执行cmd cli api的原理及兼容性设计草案
- 开放API的设计考虑--从Alisoft Saas Platform API及Google Docs API(Gadget API)的比较说起
- java1.8几个漂亮的API设计(2)排序和比较
- atitit.跨语言执行cmd cli api的原理及兼容性设计草案
- placeholder右对齐的写法,兼容性比较高的一种方法
- 为什么MVC不是一种设计模式? ---比较Backbone和Ext4.x在MVC实现上的差异
- Atitit.提升 升级类库框架后的api代码兼容性设计指南
- 为app提供api,架构该怎么设计,需要考虑高并发,访问量比较大
- 设计一个最优算法来查找一n个元素数组中的最大值和最小值。已知一种需要比较2n次的方法,请给一个更优的算法。
- Atitit.提升 升级类库框架后的api代码兼容性设计指南
- [实用] 为app提供api,架构该怎么设计,需要考虑高并发,访问量比较大
- Atitit.提升 升级类库框架后的api代码兼容性设计指南
- 一种API代码结构的设计思路
- atitit.跨语言执行cmd cli api的原理及兼容性设计草案
- 设计一个较好的框架的难点之一--API兼容性的设计
- 驱动接口API设计的一种方法
- API 设计: RAML、Swagger、Blueprint三者的比较
- 郁闷的libnet API设计
- 新写的一个商品比较控件CompareGrid,没有做设计视图。有兴趣的联络我。公布源码。