很多事情看上去很美......

首先，公司的系统虽然没有lz的那么庞大，但是分布在全国的很多城市的节点，这样的系统实现也用不了100个类，所以我可能真的对巨系统没什么概念，日访问量是千万级将近亿级的，同时在线人数大概是百万人，我们都是用节点和集群服务器解决这样的问题的。对这些节点的BI分析，显然只能用云计算的方式，很抱歉我没有负责这块，只是知道是用hadoop等实现的。
另外，我不是相信权威，我的看法是大海航行靠舵手，总要有人指出或者预示今后的方向，大家才能按照这个方向去摸索和前进，否则科技怎么快速发展呢？套用哲学的观点：事物都是呈螺旋性上升的嘛。我认为SOA,RESTful，云计算等等，这些概念都是先有方向，之后才跟进研究和实现的，自然一开始是虚的，自然有些会被证明不是必须的。
这些概念的提出和前瞻性，正是多年行业实践的经验使然，所以这样的权威我还是很景仰的。我认为我和lz的看法正好是倒了个个儿。lz应该是重实践，少理论的一类。
另外，lz所说的“每一个类都有自己特有的逻辑，那么你大量使用设计模式之后类的数量会不会减少我不知道，但我知道的是代码的行数肯定不会减少。业务逻辑的复杂性在那里，不会因为你设计模式之后就变简单。”，是你对设计模式认识不够深入的表现。设计模式的初衷就是为某个特定场景的应用提供一个最合理，最简化的实现方式。这是《设计模式》一书一开始就提到的。为什么呢？因为经过对某个特定场景的大量的实现，大家总结出了一个最好，最简洁的实现方式，这就是设计模式的形成过程。
如果你不使用设计模式去开发一个系统，用到1000个类，20万行代码，那么用设计模式重构之后，代码行数只能减少，因为不用设计模式，只能是臃肿和冗余，当然，要在正确的地方使用正确的设计模式，这就是一个具有架构师资格的职位需要做的基本事情。
如果你大量使用了设计模式进行实现，最后原始的4000个类的代码行数还是没有减少，那只能是错误的使用了设计模式。因为我觉得别说4000，恐怕不到2000个类加载到java虚拟机已经是java程序的极限了（2000我还真是随便指了个数，我做过的最巨大的系统，全国各个省份都部署节点，业务逻辑相对复杂，达到40多个模块，也不过用了300个类就实现了）。
如果java虚拟机对目前的应用系统处理出现这样的瓶颈，早应该出现一种新的规模和应用更大的编程语言来替代java了，但是目前似乎没有发现这样的瓶颈，那么在设计开发比较失败和java语言不能够处理巨系统程序二者之间，我们选谁呢？
请参看我的博文：http://sharong.iteye.com/blog/314334

顺便补充一句，我们的集群服务器,各个节点上跑的webserver都是tomcat

只能说你做的系统负载重，节点多，但业务逻辑不够复杂，所以有些东西你可能你没有注意。
JVM的内存分为堆内存和非堆内存两种，加载后的Class占用的是非堆内存。非堆内存可以通过XX:PermSize,XX:MaxPermSize参数设置.
其实像MyEclipse这样的加载类很多的插件就有可能会内存溢出，原因就是加载的类太多，非堆内存不够用了。有很多朋友已经遇到过这个问题了，MyEclipse会提示修改JVM参数的。所以说如果你没有遇到过非堆内存溢出的问题，有可能你还真是对巨系统没概念，但并不是说JAVA不能处理巨系统。

我觉得你的代码简化的经验可能是基于一些结构不是太好的代码的基础上的，通过一定程度的重构，形成良好的封装与继承，是有可能。这是基于原有代码存在重复代码、冗余代码或者重复的逻辑定式，如果不大量存在这些问题，你通过设计模式就把代码简化一半，我觉得是不可想像的。

你通过设计模式就把代码简化一半，我觉得是不可想像的。

这个不排除重构前代码质量一般。

不懂得设计模式的人来写代码就像不懂得数学公式的人来做计算，产出必然是非常繁杂，能天才如高斯，自己总结归纳出设计模式的人除外。
别说优化一半，昨天在一重构项目中用1个类、3个方法完成了此前60个类的功能，没用到框框范畴的设计模式，用到的是设计模式带给我的抽象思路。