| 什么是设计模式
设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
设计模式不是为每个人准备的，而是基于业务来选择设计模式，需要时就能想到它。要明白一点，技术永远为业务服务，技术只是满足业务需要的一个工具。我们需要掌握每种设计模式的应用场景、特征、优缺点，以及每种设计模式的关联关系，这样就能够很好地满足日常业务的需要。
设计模式要活学活用，不要生搬硬套
| 设计模式的六大原则
- 开闭原则（Open Close Principle）
开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
- 里氏代换原则（Liskov Substitution Principle）
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
- 依赖倒转原则（Dependence Inversion Principle）
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
- 接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
- 迪米特法则，又称最少知道原则（Demeter Principle）
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
- 合成复用原则（Composite Reuse Principle）
合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。
| 设计模式类型
共有 23 种设计模式。这些模式可以分为三大类：
- 创建型模式（Creational Patterns）
- 结构型模式（Structural Patterns）
- 行为型模式（Behavioral Patterns）
| 模式 & 描述 | 包括 |
|---|---|
| 创建型模式 | 单例模式（Singleton Pattern）原型模式（Prototype Pattern）工厂模式（Factory Pattern）抽象工厂模式（Abstract Factory Pattern）建造者模式（Builder Pattern） |
| 结构型模式 | 适配器模式（Adapter Pattern）桥接模式（Bridge Pattern）过滤器模式（Filter、Criteria Pattern）组合模式（Composite Pattern）装饰器模式（Decorator Pattern）外观模式（Facade Pattern）享元模式（Flyweight Pattern）代理模式（Proxy Pattern） |
| 行为型模式 | 责任链模式（Chain of Responsibility Pattern）命令模式（Command Pattern）解释器模式（Interpreter Pattern）迭代器模式（Iterator Pattern）中介者模式（Mediator Pattern）备忘录模式（Memento Pattern）观察者模式（Observer Pattern）状态模式（State Pattern）空对象模式（Null Object Pattern）策略模式（Strategy Pattern）模板模式（Template Pattern）访问者模式（Visitor Pattern） |
| 设计模式之创建篇
这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
单例模式
单例模式（Singleton）顾名思义，单例即单一的实例，确切地讲就是指在某个系统中只存在一个实例，同时提供集中、统一的访问接口，以使系统行为保持协调一致。
一个类仅有一个实例
单例模式的角色定义
Singleton（单例）：包含一个自己的类实例的属性，并把构造方法用private关键字隐藏起来，对外只提供getInstance()方法以获得这个单例对象。
原型模式
原型模式（Prototype），在制造业中通常是指大批量生产开始之前研发出的概念模型，并基于各种参数指标对其进行检验，如果达到了质量要求，即可参照这个原型进行批量生产
即用对象创建对象（克隆），而不是用类创建对象，以此达到效率的提升。
原型模式的各角色定义如下。
- Prototype（原型接口）：声明克隆方法，对应本例程代码中的Cloneable接口。
- ConcretePrototype（原型实现）：原型接口的实现类，实现方法中调用super.clone()即可得到新克隆的对象。
- Client（客户端）：客户端只需调用实现此接口的原型对象方法clone()，便可轻松地得到一个全新的实例对象。
从类到对象叫作“创建”，而由本体对象至副本对象则叫作“克隆”，当需要创建多个类似的复杂对象时，我们就可以考虑用原型模式
工厂模式
对工厂制造方法进行接口规范化，以允许子类工厂决定具体制造哪类产品的实例，最终降低系统耦合，使系统的可维护性、可扩展性等得到提升。
工厂模式可以理解为对对象构造、实例化、初始化过程的封装，不必在客户端进行实例化
因为我们完全不必关心产品的制造过程（实例化、初始化），而将这个任务交由相应的工厂来全权负责，工厂最终能交付产品供我们使用即可，如此我们便摆脱了产品生产方式的束缚，实现了与制造过程彻底解耦
工厂模式的各角色定义如下。
- Product（产品）：所有产品的顶级父类，可以是抽象类或者接口。
- ConcreteProduct（子产品）：由产品类Product派生出的产品子类，可以有多个产品子类。
- Factory（工厂接口）：定义工厂方法的工厂接口，当然也可以是抽象类，它使顶级工厂制造方法抽象化、标准统一化。
- ConcreteFactory（工厂实现）：实现了工厂接口的工厂实现类，并决定工厂方法中具体返回哪种产品子类的实例。
抽象工厂模式
抽象工厂模式（Abstract Factory）是对工厂的抽象化，而不只是制造方法
系统如果按工厂方法那样为每种产品都增加一个新工厂又会造成工厂泛滥
抽象工厂模式可以理解为工厂方法模式的高度集群化升级版
抽象工厂模式的各角色定义如下。
- AbstractProduct1、AbstractProduct2（抽象产品1、抽象产品2）：产品系列的抽象类，图中一系产品与二系产品分别代表同一产品族的多个产品系列
- ProductA1、ProductB1、ProductA2、ProductB2（产品A1、产品B1、产品A2、产品B2）：继承自抽象产品的产品实体类，其中ProductA1与ProductB1代表A族产品与B族产品的同一产品系列，之后的产品实体类以此类推。
- AbstractFactory（抽象工厂接口）：各族工厂的高层抽象，可以是接口或者抽象类。抽象工厂对各产品系列的制造标准进行规范化定义，但具体返回哪个族的产品由具体族工厂决定，它并不关心。
- ConcreteFactoryA、ConcreteFactoryB（工厂A实现、工厂B实现）：继承自抽象工厂的各族工厂，需实现抽象工厂所定义的产品系列制造方法，可以扩展多个工厂实现。
- Client（客户端）：产品的使用者，只关心制造出的产品系列，具体是哪个产品族由工厂决定。
建造者模式
建造者模式（Builder）所构建的对象一定是庞大而复杂的，并且一定是按照既定的制造工序将组件组装起来的，例如计算机、汽车、建筑物等
建造者模式又称为生成器模式，主要用于对复杂对象的构建、初始化，它可以将多个简单的组件对象按顺序一步步组装起来，最终构建成一个复杂的成品对象
建造者模式的主要目的在于把烦琐的构建过程从不同对象中抽离出来，使其脱离并独立于产品类与工厂类，最终实现用同一套标准的制造工序能够产出不同的产品。
与工厂模式的区别是：建造者模式更加关注与零件装配的顺序
建造者（Builder）模式由 4 个要素构成
- 产品
- 抽象建造者
- 具体建造者
- 指导者
建造者模式的各角色定义如下。
- Product（产品）：复杂的产品类，构建过程相对复杂，需要其他组件组装而成。比如建筑物类。
- Builder（抽象建造者）：建造者接口，定义了构成产品的各个组件的构建标准，通常有多个步骤。比如施工方接口。
- ConcreteBuilder（具体建造者）：具体的建造者实现类，可以有多种实现，负责产品的组装但不包含整体建造逻辑。比如别墅施工方类与多层公寓施工方类。
- Director（指导者）：持有建造者接口引用的指导者类，指导建造者按一定的逻辑进行建造。比如工程总监类
| 参考
# 秒懂设计模式
# 菜鸟教程
# Java设计模式：23种设计模式全面解析（超级详细）
