一个月带着读看完了设计模式，其中有一些模式真的是被坑着了，比如composite组合模式如果不用叶节点，真说不出有什么特性。再比如备忘录模式，我觉得这个模式的核心是打包传递数据，而不是用来备忘。好了，先写一个总结，以后慢慢消化

每个模式如果细说肯定不是三言两语可以概括的，但是需要简略概括，才能快速理解。

============================================================

简单工厂模式

针对一个类型多个子类的创建控制，或者说针对一个接口多种实现的控制。

最早的时候对于抽象类我有这样一个问题，接口前面加I，抽象类前面是不是应该加Abs。这个问题纠结了很久，后来突然明白了

抽象类就是一个类型的统称

鸟 = 鹰

鸟 = 麻雀

不存在任何加Abs前缀的理由。扯远了。。

简单工厂就是这样一个管理工具，不用自己再去new,再去找了。方便了代码的使用者

鸟 = 鸟工厂.鹰();

工厂模式，抽象工厂模式

这个没弄明白，目前的理解是。针对创建的创建，而进行管理。

可以把多个工厂混合在一块，而他们的创建提取为接口。

目前实际项目还没用到过

装饰器模式

简单来说，就是一个链表不断的加东西，当最后运行时，回溯回去

游戏中buff叠加计算也可以用这个模式

可能无意中就会用到这个模式

组合模式

这个模式就是装饰器模式的树形结构版本

这个模式比较恶心。。说2点个人想法。

第一 不用叶节点，当前节点的子节点用null代替。效果一样

第二 这个模式的特点是把获取数据和节点搜索分开成2个接口(安全型和透明型，其中透明型违反了李氏代换原则)。真的不知道看完之后学到了什么

命令模式

把命令的请求者和命令的执行者分开，如果发现一个类同时扮演这2个角色，就要考虑这个模式了。

是在请求者和执行者中间加一个"命令管理器"，命令的请求者在需要的时候给命令管理器添加任务就可以了。

行为型模式往往是思路的转变，要在使用中理解。 

职责链模式

这个模式个人感觉不错，代码可读性加分

举个例子，某某Boss带一群小弟出去吃饭

Boss只管吃饭，聊天，付钱。他不会去管选哪家酒店，这家酒店停车位在哪，停车如何收费，怎么预定，点餐方式是什么样的等等。这些都是他的小弟去完成的

这个模式的关键在于，判断能不能做Can slove，和去做Do something 是分开的。这样逻辑划分明确，代码可读性也就提升了

状态模式

首先这个模式千万别和switch case搞混了，完全就不是这种思路了

职责链模式是，一个环形链表不停的循环(直接for循环也可)。遇到能解决的就跳出循环。

状态模式是，一个普通链表的指针一直在到处乱跳，可能会跳到结尾就没了，或者各种状态跳个没完。

它用来解决switch case, if else过多的情况。但在可读性上反而弱了。switch case比较稳定的情况下，千万别用。

原型模式

我刚开始看原型模式的时候，认为这个和组合模式一样坑爹的玩意。。

后来无意中看了一篇博文，才发现是我用的思路不对，其实在代码中是会经常用到的

我们经常要把一个东西备份一份出来，以后再用来对比。C#是自带了Clone的

如果不用原型模式，就要把值类型参数一个一个保存下来，等用到的时候再一个一个对比(备忘录模式)

备忘录模式

备忘录模式重点不在备忘录上，而是它通过数据包传输数据的概念。

类之间互相传递的始终都是一个“包”，你不知道是什么。只有用解析的类解析完了，才知道里面是什么。

另外，备忘录模式里的宽接口，窄接口概念我至今没明白是什么意思。。（不想顾名思义去理解..但是又百度不到)

这个模式用的也不多

访问者模式

这个模式的UML类图确实有点绕，为了实现动态的函数增加，其实不止这一种方法，可以有很多方法

访问者模式这样做，性能损失是最小的。它不需要判断类型，都是重载的。

这个模式很容易误用，子类的数量要稳定这个不说了。

增加的功能，确认是不是每个子类都需要有这个新功能，如果就其中1,2个子类需要。考虑单独弄一个别的类，作为参数传进去处理(use a)

确定了之后，再选用模式。 

单例模式

单例并非只有一个实例的模式。

线程池，游戏子弹池这种数量约束概念的东西，也可以用上单例

单例是对实例对象数目的一个约束，懒汉恶汉型我觉得不必过于纠结

Facade外观模式

设计模式有4,5种是即使不学设计模式，也会无意中用到的。

外观模式就在这其中。

本来我认为没啥用，今天看敏捷开发又看到这个模式，就记一下好了。

Mediator中介者模式

外观模式是对外一致访问，达到降低耦合的目的。而中介者模式，是对内部的一个一致访问。

它把内部模块的交互部分，合并到一个中介者类里面去了。

 把普通代码重构成中介者模式也很简单，先保持对外函数不变，然后把函数里面的实现过程移到中介者类里面实现。

除非有明显的共性可以提取出来，否则用中介者模式就会有滥用模式的状况，会更难以拓展。

--------------------------------------------------------------------------------

好了，就写这个多。有些模式我实在不想写，比如外观模式。还有些模式根本用不到。

另外，推荐 设计模式纵横谈 这个讲座，在优酷上可以看到。讲的非常好

把一件事物放到一个时间线上去看待，从变化和不变化中，看出用这个模式和不用这个模式的区别

设计模式学习大体总结