为什么要自己写底层涵式_MySQL
程序员文章站
2022-04-01 11:14:30
...
有很多人在问我,既然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来.
其实这个问题对于初学者和普通的程序员是不会理解的,但当你对一门语言,不然不仅是说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来.