设计模式，今天你用了吗？

最近看了不少关于设计模式的东东，是应该总结一下下了，呵呵，纯属个人观点，有些题目比较大，只是说说我的看法吧，如有不当之处，敬请板砖轻点。

 

程序员的成长用修炼这个词形容真是恰当，修炼当然也分内功和外功了，像我们平时使用的什么Ext、Flex、Struts、Spring，如果你只是会使用, 那么也就是会这些外功了，当然你也能从这些外功的修炼中，体会到内功的重要以及内功的某些门路。外功很强，但是内功弱，同样的外功，在内功强的人手里会出神入化。

欧阳峰和十几岁的杨过都会蛤蟆功 就是比蛤蟆功 肯定是欧阳峰厉害了。为什么？欧阳峰内功厉害阿。设计模式就是很厉害的内功.

 

在项目中，我们发现貌似我们没有用那些模式阿？？那些东东难道只是看上去很美？？

其实毋庸置疑，设计模式肯定是老前辈们辛辛苦苦修炼总结出来的内功大法，而且绝对是让你功力大增的内功秘籍，那么什么时候用呢？怎么使用呢？？有什么要注意的呢？？
好，下面开始。。。。。

1、什么时候使用设计模式呢？？

敏捷以及极限编程中倡导不预先设计,不会首次使用设计模式,
我个人认为如果设计师发现是明显的需要使用设计模式,明显地属于设计模式的经典场合，那么毫不犹豫的使用,
如果发现另外的设计引入了代码坏味那么也是毫不犹豫的使用.
如果发现使用设计模式的地方可以明显提高灵活性 我也毫不犹豫的使用。

大多数开发人员还是做企业级应用，大多数人是做项目，设计模式就是先找到变化的部分并且提取出来进行封装，怎么找到变化的部分呢？？
我想还是从作产品的角度，在系统地设计开发中，发现变化的部分，想想这块逻辑是不是这个项目独有的呢？？

 

当然，你在开发的过程中，会发现某些代码属于坏味或者很适合使用设计模式呢，那么都是些什么场合呢？？可以详见《重构与模式》

 

2、怎么防止过度设计呢？？

使用设计模式，但是防止过度设计，那么怎么区分是过度设计呢？让我们去依靠嗅觉寻找代码坏味，不断重构吧

过度设计的坏味包括哪些呢？ 

(1)继承结构层次太多造成过度复杂

(2)继承与聚合不能分清楚 优先使用聚集而不是继承应该使用接口还是抽象类
继承本身没有错，关键主要是继承了不该继承的方法，这时候很可能导致增加继承类的层次，采用继承也不能像策略模式那样动态或者说运行时变化行为。

(3)过度抽象了你的接口
接口过度抽象往往造成不必要的复杂性，比如一些有时候看到很多类继承类似Common***的类，我个人认为这个时候就需要考虑是不是需要继承

 

(4)全局的公用类
我们为了在某个项目中复用某些静态方法,往往写了个大杂烩的类,包含了很多公用的方法,或者staticfinal的域.貌似好像提高了复用，实际上项目中大多数包
依赖于这种代码，造成不易拆解进行单元测试，不符合测试驱动的思想，而依赖这些类的包也往往会依赖一些本身不使用的接口，违反了接口隔离原则。

 

3、设计模式增加了设计复杂度，怎么办？？

设计模式增加了复杂度，但是这是相对的。

一方面阅读代码的人需要有设计模式的基本知识，了解设计模式的基本结构，这样可以很快地意识到这是在使用什么模式。
一方面书写代码的人需要在代码中以清晰设计意图的名称去命名你的代码，比如你想表达策略模式那么使用****stragey,你想表达装饰意图那么使用****Decrator，你想使用代理那么命名为****Proxy，这样阅读代码的人可以很快了解你的设计意图

 

4、有人说为什么在我的程序中没有使用设计模式呢？？

其实，使用设计模式的地方一定也可以采用过程化的思想去解决，只不过这种代码灵活性不高，不满足某些设计原则如开闭原则罢了。

很可能你的代码中就是存在很多这种过程化的代码，存在类的职责不清，职责过大的类或者是方法，也就是说你解决了你项目中的问题，但是灵活性不够，如果作产品，往往需要大面积的修改。

 

如果你做框架那么为了让他人扩展，设计模式是逃不过的，
如果你做企业级应用，某个项目业务逻辑虽然很复杂，但是共性的问题少，这个也是有可能的，但是也有可能你没有一双慧眼，很可能说明你不熟悉设计模式，这个原因往往是最主要的。比如你现在对代理、装饰意图区别、模板、策略的意图区别了然于胸吗？如果不是，那么还是不了解。

 

当然有时候我们并不是为了使用设计模式而使用设计模式，其实完全可以按照某些经典的设计原则去推导出某种设计结果，推导出来你发现哦原来他就是这个设计模式，当然在这个过程中，你也会发现你熟悉的某些模式帮助你得到了很好地设计，呵呵。

 

也有可能你使用了设计模式，但是不知道它是一种模式。 

5、不能只是关注设计模式阿
如果你只是学某些设计模式,你可能理解不深刻,有些面向对象的设计原则是肯定要熟悉并且深刻理解的。

(1)单一职责原则
(2)开闭原则
(3)里氏替换原则
(4)接口隔离原则

(5)这里不详细谈了

 

5、推荐几本书
《设计模式解析》第二版
《Head First 深入浅出设计模式》
《敏捷 模式、原则、实践》（书名不确切）
《重构--改善既有的代码》
《重构与模式》

都是经典，都与jolt大奖有关，其中就有不少讲解设计模式的，在这里我不得不提下《Head First 深入浅出设计模式》我个人认为是本很不错的书，读起来十分有趣，而且讲解十分到位，有一针见血的感觉。
《设计模式解析》第二版讲解非常清晰，就像是一位教授给你上课，还有习题，很正统，也非常好。

 

评论

24 楼 20055294 2010-05-17  

设计模式 ，这个东西我还没怎么接触了

23 楼 archerboy 2010-05-17  

这个帖子为什么这么多人投隐藏贴，难道是推荐书有问题？？还是帖子不符合javaeye标准

HeadFirst 也在读，设计模式解析未读过。

22 楼 zgxzowen 2010-05-17  

正在读 head first 设计模式，用诙谐的语言阐述了模式的具体应用场景，以及发模式的例证，不错的书。

21 楼 archerboy 2010-05-16  

bughammer 写道

我只是想说，请不要用你所理解的TDD的概念误导他人。嗯，实践了再说话吧。

liwenjie的观点我个人认为没有什么不妥，的确，TDD是敏捷的一个部分，敏捷整个过程放止过度设计,到底谁误导呢？呵呵

TDD，也是一个过程，但是孤掌难鸣，而且它与其他敏捷过程密不可分，所以单纯讨论TDD与过度设计没有太大意义。

bughammer 写道

根本不存在多余的代码

TDD能完全做到吗？？它只是有助于达到简单，但是它是简单的的必要条件，但不是充分条件，还要有一些设计原则指导，liwenjie在帖子中提到的的原则在很多经典著作中都有提到。

就像所看到的，项目中的bean需要spring管理吗？？你平时的项目复杂采用了spring，TDD怎么驱动出用spring呢，没有spring，程序照样跑啊？？接口也是TDD要求的啊。为什么用spring，那是因为依赖倒置原则，helloworld，也可以写一个service，一个接口，一个调用者，还可以用策略模式，不同语言策略动态替换，也可以多写几个不同语言的方法，所以具体设计方案，还是要用一些原则指导，我们现在讨论的就是这些原则。

20 楼 hatedance 2010-05-16  

bughammer 写道

如果看TDD那本薄册子，应该知道，测试失败后要做的事仅仅是写出让测试程序通过的“最小改动”。你也说了“敏捷中倡导的“简单”即满足当前需求，做出能工作的软件“。
我就比较好奇一个期望程序输出一句helloworld的测试代码如何驱动出一套spring实现的helloworld。

spring的helloworld程序应该是怎样的呢，我来搞笑一下。
首先有一个SayService,有一个方法叫sayHello(String sth);
当然得支持i18n.卡尼齐瓦，你好，。。。。
然后有DAO读取各国语言，Action做界面，AOP做事务，
TDD部分不能少，

sayService.setLanguage("zh-CN");
AssertEquals(sayService.sayHello("foo"),"你好,foo!");

19 楼 bughammer 2010-05-15  

我只是想说，请不要用你所理解的TDD的概念误导他人。嗯，实践了再说话吧。（包括楼下那位）

18 楼 liwenjie 2010-05-15  

首先，TDD 是测试驱动开发，其中包含了测试驱动设计的思想，也是一个过程和指导思想。测试驱动开发可以得到清晰的和尽可能少的依赖，可以得到松耦合，也可以得到简单的设计和代码。

完全避免过度设计不是TDD一个人的责任，他是敏捷的组成部分，TDD也不是孤立的，按照敏捷的原则、思想、过程，和其他实践（比如重构）、原则结合起来，这个过程来防止过度设计。

如何可以防止过度设计，大家可以另篇讨论。

纸上得来终觉浅，一切靠实践说话吧。

17 楼 bughammer 2010-05-15  

如果看TDD那本薄册子，应该知道，测试失败后要做的事仅仅是写出让测试程序通过的“最小改动”。你也说了“敏捷中倡导的“简单”即满足当前需求，做出能工作的软件“。
我就比较好奇一个期望程序输出一句helloworld的测试代码如何驱动出一套spring实现的helloworld。

16 楼 liwenjie 2010-05-15  

bughammer 写道

1、什么时候使用设计模式呢？
首先不应该考虑这个问题，应该考虑的是如何DRY。举个例子，比如在你绞尽脑汁为抽出两块逻辑结构完全相同，但中间的处理过程不同的代码发愁时，你自然就会去寻找一种把结构抽离出来的方法，最后也许你够聪明，自己发现了这种方法。也许你不够聪明，从网上、朋友那、同事那或者书上知道了有个叫模板模式的方法。

这个就是我说的 推导出的设计模式 或者你用了设计模式但是不知道 后来才恍然大悟 这是模版模式

bughammer 写道

2、怎么防止过度设计？
自顶向下的TDD吧，你所写出来的代码完全是由需求驱动出来的，没有测试（需求）不写代码，所以根本不会有多余的代码。

过度设计这个问题 不是TDD就完全能解决的，同样一个问题，可以有很多设计方案，就是一个helloworld，你可以写出采用复杂的代码，有人还说可以用spring把bean配置进去呢 这个没有必要，但还是TDD设计的接口啊

敏捷中倡导的“简单”即满足当前需求，做出能工作的软件，在不断重构中可能方案会越来越复杂你可以使用模式、原则，得到好的设计

15 楼 bughammer 2010-05-15  

1、什么时候使用设计模式呢？
首先不应该考虑这个问题，应该考虑的是如何DRY。举个例子，比如在你绞尽脑汁为抽出两块逻辑结构完全相同，但中间的处理过程不同的代码发愁时，你自然就会去寻找一种把结构抽离出来的方法，最后也许你够聪明，自己发现了这种方法。也许你不够聪明，从网上、朋友那、同事那或者书上知道了有个叫模板模式的方法。

2、怎么防止过度设计？
自顶向下的TDD吧，你所写出来的代码完全是由需求驱动出来的，没有测试（需求）不写代码，所以根本不会有多余的代码。

3、4，参考1。

5、DRY生万物。

6、重构值得一读，领悟这两篇帖子中gigix的话我觉得就差不多了（请无视seen）：http://www.iteye.com/topic/294651
http://www.iteye.com/topic/460125

14 楼 spyker 2010-05-15  

mococa 写道

linux1689 写道

对于中初级读者而言，个人比较推荐《设计模式之禅》，出版后在社区里反响比较强烈，大家的评价都不错，在网店和实体书店的销量也不错，具体地可以看这里：http://book.douban.com/subject/4260618/。

这本书算是在研究了原来所有设计模式类图书的优劣后写作而成的，力图使设计模式变得易懂、易学，从读者朋友的反馈来看，目的基本上达到了。当然，这本书还远非完美，肯定还存在不少问题，我们会不断收集读者反馈，然后进一步完善。

也许这个帖子会遭到一些朋友的炮轰，因为有广告的嫌疑。说句实话，是有广告的目的，但是更重要的目的是希望真正给需要的人推荐一本比较好的关于设计模式的书。

欢迎大家讨论这本书，但是不喜欢看到没有根据的指责和谩骂，一则是对自己的言行不负责任，哦二则是不尊重作者的劳动成果，三则是指责和谩骂也不能给读者建设性意见。

看见书名带“禅”的就有股装#B的味

13 楼 wangdgsc 2010-05-15  

我觉得，只要能经常回过头去看看前面完成的代码，然后将里面的坏味道给踢掉，就可以了，模式我觉得是一个比较教条的东西，理解就可以了，

12 楼 li445970924 2010-05-14  

什么情况下用模式的？ 我用得最多的就只有 单例  和工厂了 别的 实在不知道在什么场景下用  谁给讲讲

11 楼 echozhjun 2010-05-14  

是呀，整天都在写增删改代码。。。。设计模式，只是自己扩充知识时的玩物

10 楼 whaosoft 2010-05-14  

说实话啊 你要只是一个大公司里的 初级看法人员 估计用不到什么模式

9 楼 thinkx 2010-05-14  

当你还在纠结于设计模式的时候，你就还没领悟它。

8 楼 hatedance 2010-05-14  

只要你是在用java编程，你就一定离不开设计模式。
就像人与人之间必定存在父子，君臣，夫妻，姐妹，。。。等各种关系，
类之间也存在诸如父子，工厂，MVC，代理，管道，过滤，。。。等各种关系，
其中包括简单的2角关系，也包含MVC之类的3角关系，甚至4角关系。
不懂模式的人搞出来的就是属于暧昧关系。

7 楼 mococa 2010-05-14  

linux1689 写道

对于中初级读者而言，个人比较推荐《设计模式之禅》，出版后在社区里反响比较强烈，大家的评价都不错，在网店和实体书店的销量也不错，具体地可以看这里：http://book.douban.com/subject/4260618/。

这本书算是在研究了原来所有设计模式类图书的优劣后写作而成的，力图使设计模式变得易懂、易学，从读者朋友的反馈来看，目的基本上达到了。当然，这本书还远非完美，肯定还存在不少问题，我们会不断收集读者反馈，然后进一步完善。

也许这个帖子会遭到一些朋友的炮轰，因为有广告的嫌疑。说句实话，是有广告的目的，但是更重要的目的是希望真正给需要的人推荐一本比较好的关于设计模式的书。

欢迎大家讨论这本书，但是不喜欢看到没有根据的指责和谩骂，一则是对自己的言行不负责任，哦二则是不尊重作者的劳动成果，三则是指责和谩骂也不能给读者建设性意见。

看见书名带“禅”的就有股装#B的味

6 楼 xtlincong 2010-05-14  

光是设计模式，它也只是一套套完整的内功心法，是前人智慧的结晶。

想要上升到比较高的高度，除了要宏观的去学习，更重要的是像前人一样，一行一行代码去看，微观式的思考领悟。只要你走过前人的路并且走通了，那你基本学会了“独孤九剑”

5 楼 linux1689 2010-05-14  

对于中初级读者而言，个人比较推荐《设计模式之禅》，出版后在社区里反响比较强烈，大家的评价都不错，在网店和实体书店的销量也不错，具体地可以看这里：http://book.douban.com/subject/4260618/。

这本书算是在研究了原来所有设计模式类图书的优劣后写作而成的，力图使设计模式变得易懂、易学，从读者朋友的反馈来看，目的基本上达到了。当然，这本书还远非完美，肯定还存在不少问题，我们会不断收集读者反馈，然后进一步完善。

也许这个帖子会遭到一些朋友的炮轰，因为有广告的嫌疑。说句实话，是有广告的目的，但是更重要的目的是希望真正给需要的人推荐一本比较好的关于设计模式的书。

欢迎大家讨论这本书，但是不喜欢看到没有根据的指责和谩骂，一则是对自己的言行不负责任，哦二则是不尊重作者的劳动成果，三则是指责和谩骂也不能给读者建设性意见。