有很多人在问我,既然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 s += 1;
这样得到4m的字符串在我的p2上要30分钟以上,
而
stringbuffer sb = new stringbuffer();
for(int =0;i sb.append(1);
string s = new string(sb);
不到一秒.为什么不这么做呢?当然string和stringbuffer是普通程序员都知道的,但是对于更多的数据结构的效率,有几个程序员都明明白白清清楚楚?
我多次说过,所有的语言,哪怕是汇编,所有日期涵式都是从unix时间戳转换来的,
那么从这个值转换过去是最快的方法,你别看sun为你提供了dateformat,calendar等类以及一些什么after(),before()方法,它们也都是从unix时间戳来比较再转换的,为了实现通用,它们还要考虑不同国家的格式规范,
(local),所以根本不如你自己写来得更有效.
另外一方面,你要相信,标准api的开发人员并不是每个人都比你更聪明,同样的功能他们也许实现得比你更差劲,或者说你能做得比他们更好.当然绝大多数的功能他们实现得很好,这就是我,我们都还在用java语言而没有去自己重写java语言的原因,但在实际应用中,很多很多的时候,应该自己动手动手去写出更有效率,更加实用的快捷api来.