大话设计模式这本书最后有一个“OOTV”杯模式大赛，很有意思，我单独把它拿出来作为一篇手记，顺便加上一些结合实际项目使用设计模式的所思所感。
首先，在这一章中理清了设计模式的三类：创建型设计模式，结构型设计模式和行为型设计模式。先列在下面：
创建型设计模式：
单例模式，工厂方法模式，抽象工厂模式，建造者模式，原型模式
结构型设计模式：
适配器模式，装饰模式，桥接模式，组合模式，享元模式，代理模式，外观模式
行为型设计模式：
观察者模式，模版方法模式，命令模式，状态模式，职责链模式，解释器模式，中介者模式，访问者模式，策略模式，备忘录模式，迭代器模式
其实理清了设计模式的分类对我们使用设计模式是很有帮助的，比如在创建对象的时候可以参考哪些模式，在组织类之间关系要想到什么模式，遇到“坏味道”的时候要往什么方向去想。
然后又对每种设计模式进行了梳理，不同设计模式进行了比对加深了对每个模式的认识。下面主要是我对设计模式的一些想法。
1）何时想用设计模式
这个题目有点不大合适，因为什么时候我们的脑海中都要有设计模式，我的意思是什么时候想到用什么样的设计模式。其实我觉得设计模式还可以有一种分类方式，就是设计时设计模式和重构时设计模式。有些设计模式是我们在设计项目的时候就要考虑的，比如工厂方法模式，单例模式，享元模式等。还有大部分模式都是我们在最初设计时可能考虑不到的，比如我们最开始只有单一算法，想不到用策略模式结构。再如最初只有少量状态，或者少量子类，用ifelse和简单工厂完全可以驾驭，就不会先考虑工厂方法和状态模式。其实这也是完全可以的，所以我想说的有两点：第一最好在一开始设想好可能扩展的地方进行设计；第二可以先有当前最优解，当变化第一次出现的时候一定要及时修正，不然会对之后的扩展产生很不好的影响。
2）善于发现坏味道
我发现很多书，或者是课程都会把程序里面的不好的设计比喻成“坏味道”想想还挺萌的。坏味道一定是设计结构有问题，绝大部分可以通过设计模式来解决。我们举几个例子：代码冗余，累里面有大量的代码这是很常见的事情，那么这个时候很有可能违背了单一职责原则，要多职责进行重新分配。很多的ifelse或者switch结构，如果实在工厂中可以考虑用工厂方法，在其他类中可以考虑是不是可以用状态模式，职责链模式替换掉。重复代码，造成这种代码的原因肯定是因为懒，如果是整个程序共用的一些代码比如说类型转换，可以单独提出来，如果出现在某一个继承树中，就要考虑放到抽象方法中实现。
3）扩展时的痛点
其实我觉得程序员还是很乐意修改“坏味道”的，但是大部分程序员会忽略结构上的设计问题。虽然我们最初设计的时候是本着开闭原则的，但是要加新功能的时候还是避免不良想直接对原来的类进行修改甚至增添职责，久而久之维护就变得越来越难。如果要加新的功能有几种方式，首先如果这个功能可以单独提出一个类作为类的方法，那是很好的，可以用聚合代替继承。或者装饰器模式就是专门为一组子类扩展功能提供支持的一种设计模式。如果子类固定的话可以使用访问者模式来扩展方法。所以设计模式给我们的解决方案其实很多，发现老代码不易改马上反思，改新代码的时候第一反应应该是扩展。
4）不拘泥于设计模式结构
设计模式是一种思想，而不是固定的类图，这是我一直以来的理解。比如有的时候我们实现的是接口而不是继承，这样就不可以用大部分设计模式了吗，答案当然是否定的。当然这里还要说一点，就是有的时候当你觉得你用的方式和设计模式的适用范围不同的时候，第一反应还是思考一下适不适合使用这种设计模式。设计模式本身也不是没有变形，比如装饰模式可以是继承并聚合父类，也可以直接继承一个类实现。话又说回来，在完全理解设计模式思想之前还是先套模版比较稳健，虽然最终目标是活用其思想。
结语：设计模式绝对是从设计到实现到重构整个流程的程序员的利器，敢于科学的重构自己代码，敢于科学的使用设计模式，对自己对项目都是大有益处的。也希望就设计模式的问题与他人进行交流。
