文章目录
1.前言
博主经过6年的代码洗礼，慢慢意识到代码中使用设计模式的重要性。然而，在我遇到的程序员大军中，我大概归类了以下几类人：
- A类：完全没有考虑设计模式，代码完全ctrl C+ctrl V，一般是大学生居中；
- B类：听过设计模式，但是觉得深奥，不考虑入门，工作一两年的初级工程师；
- C类：合理性使用设计模式，代码维护度和扩展度很高，这是我所追求的方向。
因此，博主计划做一个设计模式的系列帖子，记录学习笔记，力求深入浅出设计模式。
如果你有以下几种想法（一个有追求的程序员），我非常建议学习设计模式：
- 架构设计时，如何实现高内聚低耦合？
- 面对产品人员提出的需求变更，我如何尽量以最少的代码改动完成任务，并且不应该旧业务？
- 如何在团队协作中沉淀出可复用组件，如何解耦？
这里先推荐几本博主阅读的设计模式书籍：
- 大话设计模式（小白推荐）
- Head First 设计模式（中文版）（小白推荐）
- 设计模式之禅（第2版）（博主极度推荐，快速看完上面小白入门可以看这个）
请记住，设计模式并不是凭空出现，而是程序员在不断地开发以及优化功能的过程中总结出的宝贵代码设计精华，用来应对各种业务需求。
2.设计模式划分
目前有23种设计模式。设计模式有两种分类方法，一种是根据模式的目的来划分，另一种根据模式的作用范围来划分。
2.1 根据模式的目的划分
根据模式是用来完成什么样的工作，可以划分为：
- 创建型模式
- 结构型模式
- 行为型模式
2.1.1 创建型模式
创建型模式用来描述“怎么创建对象，对象从哪里获取”。主要是为了将对象的创建与使用分离。包括5大模式：
- 单例模式
- 工厂方法模式
- 抽象工厂模式
- 原型模式
- 建造者模式
请记住：着重于对象如何创建，从哪里创建
2.1.2 结构型模式
结构型模式用来描述“处理类和对象的组合，将类和对象按照某种布局完成更大的结构”。包括7大模式：
- 适配器模式
- 桥接模式
- 组合模式
- 装饰模式
- 外观模式
- 享元模式
- 代理模式
请记住：着重于对象与对象之间的一种关系、布局、结构
2.1.3 行为型模式
行为型模式用于描述“类或对象之间怎样相互协作共同完成单个对象无法单独完成的任务，以及怎样分配职责”。包括11种：
- 模板方法模式
- 解释器模式
- 策略模式
- 命令模式
- 责任链模式
- 状态模式
- 观察者模式
- 中介者模式
- 迭代器模式
- 访问者模式
- 备忘录模式
请记住：着重于对象为了完成某个行为而协作的过程，重点在于行为
2.2 根据模式的作用划分
根据模式用于类上还是对象上来分，这种方式可分为：
- 类模式
- 对象模式
2.2.1 类模式
用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时便确定下来了。
- 工厂方法模式
- 适配器模式（类）
- 模板方法模式
- 解释器模式
2.2.2 对象模式
用户处理对象之间关系的，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。除了上面四个模式之外，其他模式都是属于对象模式（适配器模式比较特别）。
综合总结为下图：
当然，请记住，不要为了使用设计模式而去使用模式（这种叫做过度设计）。
3.总结
本篇没有太多的技术难点，主要是抛砖引玉，引入设计模式的概念，以及设计模式的划分。让大家有个初步的概念。请继续关注后面的博文，博主会在博文中讲解实际项目中是如何使用的。
在做小项目的时候，可以不考虑设计模式，因为有时候引入设计模式可能会额外添加更多的代码，不要让代码为设计模式服务，这是本末倒置的。
在做大项目（多人协作项目，逐步迭代的项目）的时候，博主极度建议适度考虑设计模式，因为涉及到后期的产品迭代开发，往往有意向不到的需求变更。当一个代码随着需求的变更而不用修改太多旧逻辑代码的时候，我觉得这就是一个成功的代码。
最后，博主总结几点自己的经验：
- 在涉及到创建对象的过程，可以考虑创建型设计模式
- 在涉及对象与对象之间的关系时，可以考虑结构型设计模式
- 在考虑如何增强对象行为或者对象无法单独完成某个任务时，可以考虑行为型设计模式。
下面附上脑图：
