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

嗯嗯，從邏輯的角度上看，設計模式只是一個果，在設計中權衡，分析，最后產出的一種果。
我們雖然可以到處都看到，但是并不能說它是一種工具，也不能說它是一種方法論（OO才是）
設計模式可以給我們借鑒，但是具體用還是不用，需要考慮到程序的簡潔，性能，工作量等一系列因素（如果算上工程和政治，還要考慮人手，sales等更加復雜的東東）

不敢苟同！
这些“看上去很美”的东西也许是虚的，但做为一个技术人员，剥开皮肉现骨头，掌握其本质并加以运用能将复杂问题变简单。因为国内的企业级项目不是商业驱动而是IT驱动（老板肾上腺素驱动），所以，看不到益处很正常。
一个技术人员被厂商制造出来的名词糊弄得昏了头，也很正常。
你说你写了几万个类的项目也没什么可炫耀的，项目是否优秀，不是有多少kb或复杂度，而是健康的生命周期有多长。

搞企业开发不懂设计模式，不隔屁真是一个奇迹，当然，不用OO的系统可以理解
架构师看设计模式？拜托，高程就应该全部掌握了

表达了我没能表达的意思，赞一个

我觉得你有可能对几万个类的项目没概念，如果有几个万个类，你不手动设置-XX:MaxPermSize的话，所有的类不用全加载完，JDK就会报内存溢出。

而且一个项目能做到几千个JAVA类这样的程度，本身就很说明问题，如果这些类不是自动生成的，不是千篇一律的，那么里面包含的复杂度、工作量、成本是一个很大的数目。而IT企业的老板依然是资本家，不要以为IT业的资本家就特别地笨，就不会计算成本收益，我想他们应该比你想像的要精明，当然如果你也是老板的话那就另当别论。

其实我只说做过三四千个类的项目而己，没有说几万个，而且我得说明白这些类并不全部是我写的，我不睡觉也写不了。我也不想炫耀什么，我只是想表达一种观点：很多概念很洋气，但很虚，虽然我很土蹩，但我程序确实运行的很好，而且时间也不那么短，四五年了。

用不着那么多的类，只要配置文件 足够多 尤其是ibatis的，怎么说来着，配置文件和sql一样多，只要你有速度，有力度，超度它没问题




这种业务极其复杂的项目，多发地是日本，日本的项目都外包到中国，成本不必担心
至于国内的项目，大项目不外乎电信，移动，银行===
这种项目不提也罢

这跟老板精不精明没什么关系，我想表达的意思是国内的业务变化比国外慢得多，也很少有业务创新的意识，这就给项目带来的挑战很少，这些东西也就没什么益处。


仔细整理一下你的项目在四五年之内遇到过哪些变革，你怎么去应对的，你自然就会明白很多。我们这边的项目，运行8年并还打算运行3年的都有。

投了个良好。

上面几条好像跑题了吧。

从lz的描述来看，还只是软件蓝领工人，coder的阶段。离高程，架构师还有很长的路要走。我做了7年多java程序，现在公司里SOA,云计算，设计模式等等都在大量的应用，并不是LZ所说的虚的东西。像设计模式，我熟练使用的就有16，7个，几乎每个项目都必用，而且已是手到拿来。
lz虽然自己说做的项目有3，4千个类不是xb，但是大伙儿还是能看出来lz确实是做过巨系统的，但是我想说的，通常别人的程序如果有100个类，我用设计模式设计和开发相同的功能，估计只要50个就足够了，lz懂什么是架构，重构吗？
可以说最复杂的应用，用500个类基本就可以解决了，其他的不过是简单的重复和冗余。量大并不代表系统有多巨大，可能只是一个臃肿和冗余的系统。这样的系统加载到java虚拟机，能不崩溃吗？换句话说，性能能够高吗？能够不需要架构和设计模式以及重构吗？
JDK可以说是相当庞大，无所不包了吧，sun用了多少个类来构建它？lz可以回去自己数数，不会达到lz的巨系统需要的那么多类！
正像前面回复里说的，要剥开皮肉现骨头，那才可以说是一个高水平技术人员。相信无论是美国佬还是法国佬，都不会在没有基础的东西之上，像空中楼阁般去忽悠。
现在所提出的很多概念，SOA，RESTful，WEB2.0，WEB3.0等等，很大意义上都是很多业界的资深人士，凭着自己多年的从业经验，从理论上对实践、今后的IT技术发展方向的高屋建瓴的理论指导。那么，我们在实践过程中，必然会发现一些有悖的地方和当初认识错误的概念，自然会被大家抛弃，lz看到的其实是这样一个现象。
至于AOP，IOC等等，lz是不是javaer和weber？整个struts2和springframework几乎全部是按照这种模式实现的，你只不过是在使用人家已经为你搭好的桥而已，用不着自己去AOP和IOC。整个java世界目前到处都是AOP和IOC的应用，怎么倒变成虚的了？

我三年前创业了，JAVA做了8年了，不排除我以后可能还会做软件蓝领工人，但我想目前我应该不算吧。
我不知道我离所谓高程、架构师有多远，我目前的经历中还没有被赋予此种职称。我只能说我设计过架构，可以看看我创业后的作品http://demo.zving.com，里面的CMS后台，从JS框架、UI控件体系、MVC框架、ORM实现都是我和我的同事们一手原创的。


如果你这100类里的代码不是复制粘贴的，每一个类都有自己特有的逻辑，那么你大量使用设计模式之后类的数量会不会减少我不知道，但我知道的是代码的行数肯定不会减少。业务逻辑的复杂性在那里，不会因为你设计模式之后就变简单。我想设计模式主要的作用还是提供了一种“最佳实践”，按照这种最佳实践走，你设计出可靠、可扩展性的软件的可能性比较大，但没有听说过设计模式可以简化功能实现的。


500个类包打天下的想法让我很无语，可能你对巨系统还是没有什么概念，随便指了个数。


我没有提过IOC，我也不用Spring和Struts，我自己开发的框架中曾经尝试过引入AOP，后来发现不是必须的，又去掉了。



看得出来，你还是比较相信权威的。其实我也希望被那么一套经过实践检验了的权威的软件开发方法论指引，但事实上没有。君不见，与EJB相关的大师与UML相关的权威还少吗？但他们提出的愿景实现了吗？

我对你们公司大量应用云计算很感兴趣，能有空说说吗？