何必非要OOP？

这篇文章其实是笔者多年以来的疑问感悟所成，估计各位居于不同语言阵营中的同道们也会有不少类似的疑问，愿此文抛砖引玉，与大家共同探讨。

笔者转向Java Web编程前从事的是传统的Delphi C/S编程。转过来后就觉得J2EE分层太多，每到更改，每层几乎都要涉及，相当麻烦且易出错。在Java Web之余，又涉及了一些ASP、PHP之类的东西，才发觉Web编程也可如此简单，不禁对J2EE产生了很大的疑问：本来可以简单实现的东西，何必搞得那么复杂？
近两年OO水平上涨后才逐渐领会到其中玄机。OO与分层最重要的好处其实业务逻辑及类库的复用！OOP将数据存储、业务逻辑、表示层分离，就可以适应多种数据存储方式与表示层技术的变化。比方说，你就可以选用多种数据库、XML甚至文本！也可以选择WEB、Rich Client以至于手机、PDA。当存储层与表示层变化时，业务层几乎可以保持不变。原因其实也简单：传统的过程式编程是把他们在一块写，而OO则是分开来写。而天下事总是利弊相当，OOP的高适应性也就必然为其带来高度的复杂与费时，甚至修改时的麻烦。综上所述，OOP其实是便于扩展而不适于修改。原因简单之极，写在一起的改起来只需改一处，分开写的改起来则要改每一处。
这一点上顺便提一下Sun的经典J2EE。经典J2EE其实是把OOP做到了极致，除却上述坚决的三层分离外，EJB更把数据存储层的事务与业务层的分布式特性加入其中。这对大型系统而言绝对是极大的福音。而中小型系统基本上是不需要事务与分布式的，这样一搞就让J2EE非常复杂。于是Sun的经典J2EE遭到了绝大多数中小系统应用开发者一致的口诛笔伐。可到了真正的企业级领域，J2EE的地位却难以撼动。这充分说明了OOP的极致是适应性与复杂性的综合体。这好比生物界中的生物，适应性越高的生物（如人类）必然越复杂。

是否采用OOP，OOP用到什么程度，要因软件产品的定位而论。如果考虑的是扩展性，业务逻辑相对固定，而存储层、表示层变化多的情况下，OOP当是不二之选；而存储层、表示层相对固定，业务逻辑变化大的情况下，则应选用过程式编程。如果二者变化程度均衡，则可采用MS骑墙式的方法。笔者这番大胆言论其实并非由理论推导而来，而缘于对当今软件界的实际观察。真正的企业级开发无疑J2EE是主导，这符合第一种情况；而变化迅速的互联网界则以PHP为王，小型桌面系统至今仍以VB、PB、Delphi为佳，这符合第二种情况；而中型系统，.NET发展得最好，这正是第三种情况。
所以我们搞软件的诸位同道，居于不同的阵营中，不免终日比短较长，其实是没有必要的。各种语言都有他的优势与适用范围。做好产品、服务的市场定位与技术定位，扬长避短才是明智之举。