设计模式，今天你用了吗？
最近看了不少关于设计模式的东东，是应该总结一下下了，呵呵，纯属个人观点，有些题目比较大，只是说说我的看法吧，如有不当之处，敬请板砖轻点。
?
程序员的成长用修炼这个词形容真是恰当，修炼当然也分内功和外功了，像我们平时使用的什么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 深入浅出设计模式》我个人认为是本很不错的书，读起来十分有趣，而且讲解十分到位，有一针见血的感觉。
《设计模式解析》第二版讲解非常清晰，就像是一位教授给你上课，还有习题，很正统，也非常好。
?
sayService.setLanguage("zh-CN");AssertEquals(sayService.sayHello("foo"),"你好,foo!"); 21 楼 archerboy 2010-05-16 bughammer 写道我只是想说，请不要用你所理解的TDD的概念误导他人。嗯，实践了再说话吧。liwenjie的观点我个人认为没有什么不妥，的确，TDD是敏捷的一个部分，敏捷整个过程放止过度设计,到底谁误导呢？呵呵
TDD，也是一个过程，但是孤掌难鸣，而且它与其他敏捷过程密不可分，所以单纯讨论TDD与过度设计没有太大意义。
bughammer 写道根本不存在多余的代码TDD能完全做到吗？？它只是有助于达到简单，但是它是简单的的必要条件，但不是充分条件，还要有一些设计原则指导，liwenjie在帖子中提到的的原则在很多经典著作中都有提到。
就像所看到的，项目中的bean需要spring管理吗？？你平时的项目复杂采用了spring，TDD怎么驱动出用spring呢，没有spring，程序照样跑啊？？接口也是TDD要求的啊。为什么用spring，那是因为依赖倒置原则，helloworld，也可以写一个service，一个接口，一个调用者，还可以用策略模式，不同语言策略动态替换，也可以多写几个不同语言的方法，所以具体设计方案，还是要用一些原则指导，我们现在讨论的就是这些原则。
22 楼 zgxzowen 2010-05-17 正在读 head first 设计模式，用诙谐的语言阐述了模式的具体应用场景，以及发模式的例证，不错的书。 23 楼 archerboy 2010-05-17 这个帖子为什么这么多人投隐藏贴，难道是推荐书有问题？？还是帖子不符合javaeye标准
HeadFirst 也在读，设计模式解析未读过。 24 楼 20055294 2010-05-17 设计模式 ，这个东西我还没怎么接触了