本文的目的并非是想挑起语言之争，而是希望通过客观地分析每一种主流语言的能力，辨明其长短，让程序员能够扬长避短，有效地使用各种语言。让各种语言能够各安其位，为你更好的服务。 程序员应当成为语言的主人，而不是语言的奴隶。 这里，我将比较一下几种主流编程语言：C，C++，Java，.NET，Ruby，JavaScript。 其他主流编程语言，如Pascal,Delphi，我不太熟悉。希望熟悉的朋友能够补全对这些语言的评价。 至于Basic，它的版本差异很大，而且能力不太全面，这里也不做评价。阅读全文>
发表于 @ 2008年06月10日 00:19:00|评论(loading...)|收藏
本文的目的是想告诉大家，为什么C++的模板这么强大。为什么Ruby的Duck Typing（像鸭子那样编程）这么强大！
基于对象和面向对象编程共有三种范式。它们提供了强大的动态或者静态多态能力，使用它们编程，将令你的程序面向抽象，易于更换。
1，“模板支持的基于对象”的编程范式。这种编程范式适用于静态类型的语言。提供了静态多态的能力。典型的如C++。
2，“静态类型语言”的面向对象的编程范式。这种编程范式适用于静态类型的语言。提供了动态多态的能力。典型的如Java，NET。
3，“动态类型语言”的基于对象的编程范式。使用Duck Typing“像鸭子一样编程”的编程理念。这种编程范式适用于动态类型的语言。它们有类型，但是变量不确定类型。典型的如Ruby。这也实现了动态的多态能力。
阅读全文>
发表于 @ 2008年06月09日 01:41:00|评论(loading...)|收藏
在《Java路径问题最终解决方案—可定位所有资源的相对路径寻址》一文中，我给大家提供了一个助手类ClassLoaderUtil ，和它的public static URL getExtendResource(String relativePath)方法。这个方法能够接受“../”这样的参数，允许我们用相对路径来定位classpath外面的资源。这样，我们就可以使用相对于classpath的路径，定位所有位置的资源！
本文中，我给大家提供了一个在JavaEE程序中使用这个便利方法寻找相对路径的代码实例。
在《JavaEE路径陷阱之getRealPath》一文中，探讨了JavaEE程序中资源寻址的问题，有兴趣的读者可以看看那篇文章。
阅读全文>
发表于 @ 2006年12月03日 14:32:00|评论(loading...)|收藏
本文是《Java路径问题最终解决方案—可定位所有资源的相对路径寻址》一文的姐妹篇。请同时阅读该文。
JavaEE程序有一大路径陷阱，那就是ServletContext的getRealPath方法。我们常常使用getRealPath(“/”)来获得Web应用程序根目录的绝对路径。这是绝对要不得的！提供这个方法绝对是JavaEE API开发组的一大败笔。使用它，我们会万劫不复！
绝对不要使用ServletContext的getRealPath方法获取Web应用的路径！应该使用ServletContext的getResource()方法，直接使用相对于Web应用根目录的相对路径来获取资源。
阅读全文>
发表于 @ 2006年12月03日 12:17:00|评论(loading...)|收藏
Java的路径问题，非常难搞。最近的工作涉及到创建和读取文件的工作，这里我就给大家彻底得解决Java路径问题。
我编写了一个方法，比ClassLoader.getResource(String 相对路径)方法的能力更强。它可以接受“../”这样的参数，允许我们用相对路径来定位classpath外面的资源。这样，我们就可以使用相对于classpath的路径，定位所有位置的资源！
...........................................................................................
尽量使用相对classpath的相对路径。不要使用绝对路径。使用上面ClassLoaderUtil类的public static URL getExtendResource(String relativePath)方法已经能够使用相对于classpath的相对路径定位所有位置的资源。
阅读全文>
发表于 @ 2006年12月03日 01:34:00|评论(loading...)|收藏
今天，发现了一个以前写的使用Spring声明式事务管理的程序爆出了数据库连接错误，感觉是非常典型的一个误用Spring声明式事务管理的例子，拿出来为大家点评一下。..................................
不能再把一切扔给框架、容器、工具！首先理解你的业务逻辑，理解你要实现的功能，然后搞清楚框架、容器、工具会帮助我们做什么。只有理解了自己的业务逻辑，理解了自己的代码，理解了自己要用到的第三方代码，才能真正完美地实现我们需要的功能！
阅读全文>
发表于 @ 2006年12月01日 00:21:00|评论(loading...)|收藏
良好的面向对象的程序，一般都使用接口和实现分离的模式。我在《事务管理最佳实践全面解析》一文中提出，用*Transaction和*Dao后缀这样的形式，区分方法的不同用途。
这样，可以提醒接口的实现者和方法的使用者注意到它们对于数据库连接和事务的依赖。
实际上，使用*Transaction后缀这样的命名方式，对于声明式事务管理也是很有用处的。如，Spring的事务管理中，我们一般使用方法名的匹配来应用声明式事务。
..................................................................................................
阅读全文>
发表于 @ 2006年11月29日 08:25:00|评论(loading...)|收藏
事务管理最佳实践多余的话之一
----“每次请求，一次数据库连接，一次事务”是不是金科玉律？
《事务管理最佳实践全面解析》 一文发表之后，关于事务管理最佳实践，还有一些未尽之言。今天又想到一些，所以就撰写了这篇文章，对该文进行一些补充。不知道会不会还有其他“多余的话”。为了避免以后文章的标题写成《事务管理最佳实践更多余的话》，《更更多余的话》…所以，这篇文章的标题就是
《事务管理最佳实践多余的话之一》，不知道会不会还有之二、之三。
本文论述“每次请求，一次数据库连接，一次事务”是不是金科玉律？这个问题。
阅读全文>
发表于 @ 2006年11月27日 22:59:00|评论(loading...)|收藏
写作这篇文章的起因，是前一段时间，我使用Jbpm工作流引擎开发工作流管理系统的过程中，使用编程方式管理事务时遇到的问题。
由于之前很长一段时间，我一直都在使用Spring和EJB容器的声明式事务管理，因此，咋一遇到Jbpm这样的编程方式管理事务的情况，一下子搞不定了！经过几天的研究，我重新思考了怎样进行事务管理这个问题，并且发明了一种非常好的编程范式，或者说是事务管理的最佳实践。不敢独享，拿出来与诸君共赏。请大家批评指正。
...........................................................................................
综上所述，可以看到，我提出的这一套事务管理最佳实践是一套非常灵活、强大、简洁的管理事务的最佳实践。具有极其强大的适应能力。采用这套编程范式，你可以很容易地彻底摆脱事务管理带来的困扰！
使用它，即使是编程方式管理事务，也是非常简单而可爱的。
阅读全文>
发表于 @ 2006年11月27日 00:03:00|评论(loading...)|收藏
性能和开发效率之争，是编程世界恒久的话题。来自不同开发技术背景的程序员对此有不同的看法。性能和开发效率孰轻孰重，这个问题没有普遍适用的答案。对于某些要求高性能的特定应用，肯定是高性能更重要一些。但是，对于绝大部分的软件开发领域，应该来说，还是开发效率比性能更重要一些。
操作系统的没落和虚拟机的崛起，表明性能和开发效率的权衡中，一般情况下，还是开发效率更重要。微软、SUN，所有采用.NET和Java的厂商都同意这一点。你呢？
阅读全文>
发表于 @ 2006年11月19日 12:39:00|评论(loading...)|收藏