设计模式总结（《Head First设计模式》学习总结）

写在前面：

学习过程当中不只要熟练掌握技能，理论的消化吸取也必不可少。虽然我的更倾向于学习技术类的东西（短期的精力投入很快就能看到成效...），但看了不少前辈的经验总结后才知道理论性的东西是绝对不能忽视的，毕竟理论对实践有着重要的指导意义。而了解“设计”相关的东西，会对“实现”产生潜移默化的影响，虽然不能在短期内看到让人欣喜的变化，但可能有一天回过头来一想“哦~，原来我这个不错的小习惯是当年在那本书上学到的啊”

一.什么是设计模式？

绕了一圈以后让咱们又回到这个话题吧（看书以前问本身一遍，看完以后再问本身一遍，答案之间的差别就是感悟了）

以前：

自问：设计模式是什么？

自答：是一些系统设计的指导原则吧，不过我如今每天写代码，应该也用不到设计层面上的东西。

自问：哦，那具体是什么？

自答：不清楚，不过我见过一些前辈的代码，结构很复杂，一看就很上档次的那种，那些应该就用了设计模式吧，因此代码有没有应用设计模式应该就是高手与新手的区别了。等我成了高手以后，这种东西还不信手拈来，嗯，不说了，我写代码去了，好好积累项目经验。

...

以后：

自问：设计模式是什么？

自答：设计模式是由代码结构优化经验萃取出来的理论知识，应用成熟的设计模式可以加强代码的可复用性、可扩展性与可维护性。

自问：你好像很专业的样子，那好，既然设计模式有这么多好处，那是否是应用了设计模式的设计都是好设计？

自答：固然不是，咱们不能为了使用模式而使用模式。设计模式可不能滥用，毕竟应用设计模式必需要做出一些牺牲（好比增长类结构的复杂性...），因此滥用设计模式的话是会出事的。并且，就算咱们有了锤子，也不能把全部问题都看做钉子吧？

...

P.S.还记得学习正则表达式的总结：能不用就尽可能不要用（最大限度的避免滥用），设计模式与之相似，不能看到什么问题都往模式上靠，只有当咱们很是肯定在当前情景下确实须要用设计模式来优化咱们的设计时，才考虑使用设计模式（至于到底用不用，还要权衡重构的成本与优化的收益...）

二.要不要使用设计模式？

这是个值得思考的问题，毕竟如今咱们已经拥有了一把锤子，要不要用它固然成了问题，毕竟不是全部的问题均可以用锤子来解决。退一步讲，即使全部问题都能用锤子解决，咱们也不肯定使用锤子是否是最好的解决方案（拔钉子的话，可能用钳子更好些...）

当咱们拿着某个设计模式想放进咱们的代码中时，最好权衡一下利弊，诚然，设计模式具备的设计上的弹性必定会给咱们以后的维护变动带来些便利。可是利与弊到底哪一个更多一些，咱们须要先回答几个问题再作决定：

• 咱们的项目是否是几乎不涉及维护或者没有后续版本，那么咱们引入设计模式还有必要吗？
• 咱们项目的规模是否是大到了不用设计模式不行的地步？
• 这个设计模式用在这里合适吗？有没有更合适的？
• 非要用设计模式吗？可不能够用几个简单的设计原则来代替？
• 引入设计模式以后，代码结构的复杂度大大增长，重构的成本咱们能够接受吗？

若是深思熟虑以后，仍是以为使用设计模式比较好，那么，放心去用吧，以后好好享受设计模式带来的好处吧

三.设计原则总结

设计原则都是一些简单的指导意见，没有固定的实现，于是设计原则也更加灵活，常见的设计原则以下：

1. 封装变化（把易于发生变化的部分抽出来，以减小其变化对其它部分的影响）
2. 多用组合，少用继承（组合比继承更有弹性）
3. 针对接口编程，不针对实现编程（使用接口能够避免直接依赖具体类）
4. 为交互对象之间的松耦合设计而努力（更松的耦合意味着更多的弹性）
5. 类应该对扩展开放，对修改关闭（open-close原则）
6. 依赖抽象，不要依赖具体类（减小对具体类的直接依赖）
7. 只和朋友交谈（密友原则）
8. 别找我，我会找你（Don't call me, I will call you back.安卓开发的大原则）
9. 类应该只有一个改变的理由（单一责任原则）

能用设计原则解决的问题就不要用设计模式（杀鸡焉用宰牛刀...），由于设计原则实现起来更加灵活，更加轻巧（不用去考虑模式的条条框框...）

四.设计模式总结

名称	特色
策略模式（Strategy）	把能够替换的算法步骤封装成一个个算法族，供运行时动态选择
观察者模式（Observer）	定义并维护对象之间的一对多关系
装饰者模式（Decorator）	创建拥有共同超类的装饰者与被装饰者来实现功能的动态扩展
工厂模式（Factory）	封装对象的建立过程，包括工厂方法模式和抽象工厂模式
单件（例）模式（Singleton）	用来建立惟一的对象（好比数据库链接对象，线程池对象等等）
命令模式（Command）	封装方法调用细节，解耦请求者与执行者
适配器模式（Adapter）	用来实现不一样接口间的转换
外观模式（Facade）	为复杂的子系统提供简单易用的高层接口
模版方法模式（Template Method）	用来封装算法骨架（流程），某些步骤由子类实现
迭代器模式（Iterator）	用来封装遍历细节
组合模式（Composite）	提供一种层级结构，使得咱们可以忽略对象与对象集合间的差别，一视同仁地对待它们
状态模式（State）	把全部动做都封装在状态对象中，状态持有者将行为委托给当前状态对象
代理模式（Proxy）	经过插入第三方（代理对象）来分离调用者和被调用者（不一样于执行者）
复合模式（Compound）	将多个模式组合结合起来造成一个“框架”，以解决通常性问题
桥接模式（Bridge）	将抽象的控制类与具体实现类经过组合解耦，使得抽象层类与实现层类能够对立与对方而变化
生成器模式（Builder）	用来封装组合结构（树形结构）的构造过程，与迭代器模式相似，都隐藏了组合结构的内部实现，只提供一组用于建立组合结构的接口
责任链模式（Chain of Responsibility）	让一个请求能够被一组接收者顺序处理，相似于Android处理请求的方式：一个接收者捕获请求后能够return true消费掉请求，也能够return false传递给接收者队列中的下一个接收者（观察者）
蝇量模式（Flyweight）	抽象出对象管理层来统一管理大量的同类型对象，以减小运行时对象实例的个数，减小内存消耗
解释器模式（Interpreter）	用来为简单语言建立解释器，将语法规则直接映射为各个类，结构简单，但效率较低
中介者模式（Mediator）	引入中介者来封装多个对象间的复杂交互，以下降同级（在类结构统一层次上的）对象间的依赖
备忘录模式（Memento）	支持对象状态的保存与恢复，并将对象状态数据封装起来，独立于客户代码以提供保护（Java中能够结合序列化反序列化技术来实现该模式）
原型模式（Prototype）	以现有的对象为原型，经过clone获得新的对象（以简化新对象的建立过程）
访问者模式（Visitor）	为组合结构添加新的操做，而不须要频繁的改变组合结构

 

五.面向对象的设计（Object Oriented Design）

一直伴随着OOD的问题就是“折衷”（或者说是“取舍”），最简单的例子——要不要用设计模式？

• 用，意味着将产生复杂的类关系，多层的抽象，咱们将牺牲易读性换取易扩展性、易维护性或者其它特性
• 不用，意味着咱们不须要对现有代码进行重构（或者不用去在复杂的设计上耗费过多的时间），但使用设计模式的全部好处咱们就都享受不到了

两者选其一，这就是一个“取舍”，或者创造第三个选项（好比使用设计原则），这就是一个“折衷”

写在后面：关于《Head First设计模式》

不多写书评，由于每一个人的喜爱不一样，很差做推荐（甚至有时候喜欢一本书仅仅是由于喜欢做者的行文风格而已，从而不自觉的认为书籍内容不错。。）

这本书是前辈推荐的，看完以后以为大部分章节讲的很不错，既细致又通俗，但感受某些章节并非很好（好比第一章策略模式的例子不很贴切，和后面的远程代理部分细节展开的不合理）

整体来讲，做为入门书籍的话，《Head First设计模式》仍是不错的，我的感觉，仅供参考