当前页面: 开发资料首页 → JSP 专题 → 为什么要自己写底层涵式

为什么要自己写底层涵式

摘要: 为什么要自己写底层涵式

有很多人在问我,既然SUN或第三方已经为我们提供足够多的API,我们为什么还要自己写底层涵式?
其实这个问题对于初学者和普通的程序员是不会理解的,但当你对一门语言,不然不仅是说JAVA,精通到一定的程序时,你就自然地理解了-----你不再想用别人为你设计的涵式,因为你相信你自己写的涵式的实现过程比别人提供给你的更strong.
这个strong的标准应该上效率更高,功能更好(不是更多).

我们先把SUN和第三方软件商提供的API叫标准API,我们自己的就叫快捷API,
标准API的特点是通用,为了这个通用,就要付出一定的资源,就象JAVA本身为了通用就要先实现JVM,一个普通的BEAN,它的业务逻辑可能只有一行代码,但为了照顾那些菜鸟级的客户程序员,BEAN的设计者们(服务程序员)不得不花更多的时候来写BEAN的接口.就是所谓的规范:以80%的资源来完成业务逻辑以外的功能.

就比如JAVAMAIL,在一个MAIL系统中,真正实现非常完整的MAIL功能的API大约有30个左右,但JAVAMAIL为了基于"消息机制"这一规范,无论从效率还是从易用性方面都成了邮件系统中的垃圾,我自己虽然学过好多种语言,但我对JAVA语言有一种狂热.我这样评价JAVAMAIL并不影响我对JAVA语言和JAVA技术的热爱.
可以说,JAVA开发小组的人员已经不是原来的那些精英了,他们最初的思想并没有被一直发扬,就JAVAMAIL本身来说,他们已经从思想退化到程式的水平------为了通用而故意通用,结果陷入了难用的泥坑.

对于我们来说,如果你对JAVA技术的实现非常了解,自己写涵式解决问题是一个最有效的手段.比如我们明知道String的+操作在底层是StringBuffer的append()操作,为什么不在程式中直接这样做呢?如果你这样你会获得惊人的效率:
String s = "";
for(int =0;i<1024*1024*4;i++)
s += 1;
这样得到4M的字符串在我的P2上要30分钟以上,
而
StringBuffer sb = new StringBuffer();
for(int =0;i<1024*1024*4;i++)
sb.append("1");
String s = new String(sb);
不到一秒.为什么不这么做呢?当然String和StringBuffer是普通程序员都知道的,但是对于更多的数据结构的效率,有几个程序员都明明白白清清楚楚?

我多次说过,所有的语言,哪怕是汇编,所有日期涵式都是从UNIX时间戳转换来的,
那么从这个值转换过去是最快的方法,你别看SUN为你提供了DateFormat,Calendar等类以及一些什么after(),before()方法,它们也都是从UNIX时间戳来比较再转换的,为了实现通用,它们还要考虑不同国家的格式规范,
(local),所以根本不如你自己写来得更有效.

另外一方面,你要相信,标准API的开发人员并不是每个人都比你更聪明,同样的功能他们也许实现得比你更差劲,或者说你能做得比他们更好.当然绝大多数的功能他们实现得很好,这就是我,我们都还在用JAVA语言而没有去自己重写JAVA语言的原因,但在实际应用中,很多很多的时候,应该自己动手动手去写出更有效率,更加实用的快捷API来.

最后说说,如何能写出更好的API.
首先你要对现有的API非常熟悉,那些连什么随机数API都不知道还要问人的人不要再看了,你们应该好好地下一些真功夫在JAVA语言本身上,而不要急于做一些项目,你们现在要做的不是项目,而是作业.

对JAVA语言有了相当的了解后,提高一个档次,深入地理解一个JAVA技术.
然后回过头来,再深入JAVA语言,就是说在功夫到了七层左右,先要对十层的境界有一个概览再回头练八层.这时你把JDK的几个jar文件都展开了,然后把目录结构打印出来,对每个包下的每个类这样的整体结构的目录树先熟悉,然后每天对其中的几个jad出来,看看SUN的实现过程,吹毛求疵!!!不是为了和他们过不去,是为了加深记忆和理解.
如果没有足够的时候,至少对常用的类要做到以上的要求.

接下来,你要学习的是JAVA语言的调试技术,不要用任何工具,就用命令行.
熟悉以后学习JAVA虚拟机规范,这是你成为高手的关键.

经过以上学习,当然在学习中为了解决一些问题你已经无意地学了更多地东西.
你自己试试看,自己写一个String类,把jdk中的那个给replace了看看,如果一切没问题你应该可以是真正的高手了.这时你一定会感觉到自己写API的效率和乐趣了.

↑返回目录
前一篇: JSP(JSTL)中如何使用常量防止硬编码?
后一篇: HTTP标准的请求和响应