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

　　EJB看上去很美，很多“企业级特性”，不知道成就了多少中间件厂商。但用的人都说很难搞，让我很怀疑。直到有一天一位大佬高呼“Without EJB”，一时风云变色，群EJB束手。

　　UML看上去很美。当时简直是不会用Rose不敢出去见人，有人宣称“若干年之后，不通UML者无法染指软件开发”。当时听人天天念着Rational的名字，告诉我可以用Rose从UML直接生成Java代码C代码C++代码，满眼都是星星。但我一直都没学得好，好在现在不用UML也没人鄙视我了。

　　MDA看上去很美。当时铺天盖地的大大的MDA印在杂志上，挂在网页上，似乎只需要掌握了领域知识，建立了领域模型，就直接可以生成代码。那时候微软给我的印象就是：Microsoft=MDA，VisualStudio.NET=MDA。这个一直没弄明白也没实际操作过，但现在似乎很少有人提了。
　　
　　XP看上去很美。当时图书馆的书架上，印有XP与极限编程的书竟然和印有JSP、J2EE字样的书数量不相上下。但最流行的时候我是一个小兵，没有办法实行，慢慢地也不太热了。

　　AOP看上去很美。不知道多少人以为一种影响深远的编程模式即将出现，书似乎也出了不少。结果最终发现能用到的地方实在太少，慢慢地很少有人提了。

　　设计模式看上去很美。这个倒真是有点美，学习一下思想很不错。只是程序写了很多年，只有单例模式用得最多，工厂都用得少，始终没给其他模式找到必须用他们的理由，慢慢地很多设计模式都忘了。

　　SOA看上去倒是不知道美不美，但天天被人灌输，似乎也很美。只是自从我知道这个名词以后，就从没真正弄明白过他到底是美在哪里，只是前年高人甲承认SOA还未落到实处，去年高人乙说SOA即将大红大紫，今年翻开杂志，又见高人丙说SOA在中国缺乏有说服力的成功案例云云。

　　Grid看上去很美。Oracle 10g的这个小g不知道让多少人心潮澎湃，最终发现离我们老百姓实在太远。

　　云计算看上去很美。只是不知道跟Gird有什么差别，巨头们说的一个和一个不同。最近看见一个.NET的CMS也说什么云计算，真是不知所云。

　　年复一年，终于觉得不能被人继续忽悠下去了。不再奢望能够有神奇的工具可以让我直接画画图就能得到一个可以工作的程序；不再相信有什么特别的方法可以极大地提高开发效率；不再相信巨头们的话，如果有什么新的概念是由巨头们掀起的，我决定以后一律先等五年。

　　1995年布鲁克斯说：“没有银弹”，但他很谦虚地指定了一个期限：“十年内”，事实证明老先生没有错，只是高估了后辈们的能力。

评论

34 楼 RCFans 2009-06-10  

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

33 楼 mathgl 2009-06-10  

wyuch 写道

sharong 写道

首先，公司的系统虽然没有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

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

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

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

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

32 楼 wyuch 2009-06-06  

sharong 写道

首先，公司的系统虽然没有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

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

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

31 楼 sharong 2009-06-06  

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

30 楼 sharong 2009-06-06  

首先，公司的系统虽然没有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

29 楼 wyuch 2009-06-06  

sharong 写道

从lz的描述来看，还只是软件蓝领工人，coder的阶段。离高程，架构师还有很长的路要走。我做了7年多java程序，现在公司里SOA,云计算，设计模式等等都在大量的应用，并不是LZ所说的虚的东西。像设计模式，我熟练使用的就有16，7个，几乎每个项目都必用，而且已是手到拿来。

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

sharong 写道

lz虽然自己说做的项目有3，4千个类不是xb，但是大伙儿还是能看出来lz确实是做过巨系统的，但是我想说的，通常别人的程序如果有100个类，我用设计模式设计和开发相同的功能，估计只要50个就足够了，lz懂什么是架构，重构吗？

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

sharong 写道

可以说最复杂的应用，用500个类基本就可以解决了，其他的不过是简单的重复和冗余。量大并不代表系统有多巨大，可能只是一个臃肿和冗余的系统。这样的系统加载到java虚拟机，能不崩溃吗？换句话说，性能能够高吗？能够不需要架构和设计模式以及重构吗？

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

sharong 写道

至于AOP，IOC等等，lz是不是javaer和weber？整个struts2和springframework几乎全部是按照这种模式实现的，你只不过是在使用人家已经为你搭好的桥而已，用不着自己去AOP和IOC。整个java世界目前到处都是AOP和IOC的应用，怎么倒变成虚的了？

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



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

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

28 楼 sharong 2009-06-06  

从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的应用，怎么倒变成虚的了？

27 楼 Else 2009-06-05  

投了个良好。

上面几条好像跑题了吧。

26 楼 RCFans 2009-06-05  

wyuch 写道

不要以为IT业的资本家就特别地笨，就不会计算成本收益，我想他们应该比你想像的要精明，当然如果你也是老板的话那就另当别论。

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

wyuch 写道

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

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

25 楼 iaimstar 2009-06-04  

引用

你不手动设置-XX:MaxPermSize的话，所有的类不用全加载完，JDK就会报内存溢出

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

引用

而且一个项目能做到几千个JAVA类这样的程度，本身就很说明问题，如果这些类不是自动生成的，不是千篇一律的，那么里面包含的复杂度、工作量、成本是一个很大的数目。

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

24 楼 wyuch 2009-06-04  

RCFans 写道

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

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

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

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

23 楼 wyuch 2009-06-04  

halida 写道

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

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

22 楼 RCFans 2009-06-04  

wyuch 写道

其实我的意思跟你的基本差不多，设计模式还是比较美的，但实际上用的确实很少，毕竟我们主要还是搞企业开发的，既不搞GUI库，也不做Stuts、Hibernate。

所以我觉得对于普通程序员来说，不要太看重设计模式，也不要花太多时间在设计模式上，因为用不着，不知道你同不同意我看法？等成长为架构师以后，有了一定的经验了，再去看看设计模式，也许会比较有效果。

我另一个意思是说设计模式并不是必不可少，就像Decorator，有很多IO库并没有用。所以用不用一个模式并不是绝对的，用了可能会效果比较好，但不用也不一定就不好。作为一个技术积累的公司，很式问题都已经形成了类库，可能这个类库并没有用设计模式，但只要实际使用中效果好，那就可以了。

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

21 楼 RCFans 2009-06-04  

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

20 楼 halida 2009-06-04  

wyuch 写道

Else 写道

其它不好说，但是lz对设计模式这个东西的观点我不同意

你没用过不代表别人没用过

Observer 模式 到处都有用到，只要与GUI相关的,Swing,Ext,gwt。

Singleton 不说了，太多

Factory现在用的少了，因为有了IOC

Interpreter 模式, SSH里面都有用到，还有MINA。

Template 模式,HibernateTemplate和JdbcTemplate谁没用过,Spring的卖点之一

Builder 模式,Google Protoc Buffer 里面有用

Decorator 模式和Bridge模式，java.io里面有用，要理清这些Stream的的关系，就必须了解Decorator 模式

command模式，struts1的基石

太多了，我所了解的就这些，实际上用过的很少，因为框架把你的工作都做了，并不是代表这些设计模式没有用。

其实我的意思跟你的基本差不多，设计模式还是比较美的，但实际上用的确实很少，毕竟我们主要还是搞企业开发的，既不搞GUI库，也不做Stuts、Hibernate。

所以我觉得对于普通程序员来说，不要太看重设计模式，也不要花太多时间在设计模式上，因为用不着，不知道你同不同意我看法？等成长为架构师以后，有了一定的经验了，再去看看设计模式，也许会比较有效果。

我另一个意思是说设计模式并不是必不可少，就像Decorator，有很多IO库并没有用。所以用不用一个模式并不是绝对的，用了可能会效果比较好，但不用也不一定就不好。作为一个技术积累的公司，很式问题都已经形成了类库，可能这个类库并没有用设计模式，但只要实际使用中效果好，那就可以了。

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

19 楼 iaimstar 2009-06-04  

代理模式用的铺天盖地 － －

18 楼 wyuch 2009-06-04  

Else 写道

其它不好说，但是lz对设计模式这个东西的观点我不同意

你没用过不代表别人没用过

Observer 模式 到处都有用到，只要与GUI相关的,Swing,Ext,gwt。

Singleton 不说了，太多

Factory现在用的少了，因为有了IOC

Interpreter 模式, SSH里面都有用到，还有MINA。

Template 模式,HibernateTemplate和JdbcTemplate谁没用过,Spring的卖点之一

Builder 模式,Google Protoc Buffer 里面有用

Decorator 模式和Bridge模式，java.io里面有用，要理清这些Stream的的关系，就必须了解Decorator 模式

command模式，struts1的基石

太多了，我所了解的就这些，实际上用过的很少，因为框架把你的工作都做了，并不是代表这些设计模式没有用。

其实我的意思跟你的基本差不多，设计模式还是比较美的，但实际上用的确实很少，毕竟我们主要还是搞企业开发的，既不搞GUI库，也不做Stuts、Hibernate。

所以我觉得对于普通程序员来说，不要太看重设计模式，也不要花太多时间在设计模式上，因为用不着，不知道你同不同意我看法？等成长为架构师以后，有了一定的经验了，再去看看设计模式，也许会比较有效果。

我另一个意思是说设计模式并不是必不可少，就像Decorator，有很多IO库并没有用。所以用不用一个模式并不是绝对的，用了可能会效果比较好，但不用也不一定就不好。作为一个技术积累的公司，很式问题都已经形成了类库，可能这个类库并没有用设计模式，但只要实际使用中效果好，那就可以了。

17 楼 Else 2009-06-04  

其它不好说，但是lz对设计模式这个东西的观点我不同意

你没用过不代表别人没用过

Observer 模式 到处都有用到，只要与GUI相关的,Swing,Ext,gwt。

Singleton 不说了，太多

Factory现在用的少了，因为有了IOC

Interpreter 模式, SSH里面都有用到，还有MINA。

Template 模式,HibernateTemplate和JdbcTemplate谁没用过,Spring的卖点之一

Builder 模式,Google Protoc Buffer 里面有用

Decorator 模式和Bridge模式，java.io里面有用，要理清这些Stream的的关系，就必须了解Decorator 模式

command模式，struts1的基石

太多了，我所了解的就这些，实际上用过的很少，因为框架把你的工作都做了，并不是代表这些设计模式没有用。

16 楼 zbird 2009-06-04  

maomiandyou 写道

看到这篇帖子我想起了一句歌词

醉拳里面唱到
江湖闯名号，从来不用刀

但是我又说不出来为什么？
谁给分析下我的潜意识

功夫再高也怕菜刀

15 楼 lordhong 2009-06-04  

PICC是人保?  哇哈哈哈哈, 强烈鄙视一下...