七大设计原则

• 单一职责原则

• 接口隔离原则

• 依赖倒置原则

• 里氏替换原则

• 迪米特法则

• 合成复用原则

概括

共23种设计模式

创建型5种：工厂方法、抽象工厂、单例模式、建造者模式、原型模式，这里经常提到简单工厂模式，不属于23种设计模式

结构型7种：适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享元模式

行为型11种：策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介模式、解释器模式

创建型

单例设计模式（Singleton）

基本概念

定义：确保一个类只有一个实例，并提供一个全局访问点

单例模式的三个要素：1、此类只能有一个实例 2、此类必须自行创建这个实例 3、必须自行向整个系统提供这个实例

优点：可以严格控制怎样和何时访问它；由于系统内存中只存在一个对象，因此可以节约系统资源，提高性能

缺点：由于没有抽象层，因此不易扩展；单例类的职责过重，违背“单一职责原则”。

适用情况：系统只需要一个实例对象，调用类的单个实例只允许使用一个公共访问点。

建造者模式（Builder）

概念：

创建者模式又叫建造者模式，是将一个复杂的对象的构建与它的表示分离，使

得同样的构建过程可以创建不同的表示。创建者模式隐藏了复杂对象的创建过程，它把复杂对象的创建过程加以抽象，通过子类继承或者重载的方式，动态的创建具有复合属性的对象。

建造者模式是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。建造者模式属于对象创建型模式。根据中文翻译的不同，建造者模式又可以称为生成器模式。

​ 适用场景：

隔离复杂对象的创建和使用，相同的方法，不同执行顺序，产生不同事件结果

多个部件都可以装配到一个对象中，但产生的运行结果不相同

产品类非常复杂或者产品类因为调用顺序不同而产生不同作用

初始化一个对象时，参数过多，或者很多参数具有默认值

Builder模式不适合创建差异性很大的产品类

产品内部变化复杂，会导致需要定义很多具体建造者类实现变化，增加项目中类的数量，增加系统的理解难度和运行成本

需要生成的产品对象有复杂的内部结构，这些产品对象具备共性；

模式结构：

建造者模式包含如下角色：

Builder：抽象建造者

ConcreteBuilder：具体建造者

Director：指挥者

Product：产品角色

简单工厂模式

定义：在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

模式结构：

简单工厂模式包含如下角色：

Factory：工厂角色 工厂角色负责实现创建所有实例的内部逻辑 Product：抽象产品角色 抽象产品角色是所创建的所有对象的父类，负责描述所有实例所共有的公共接口 ConcreteProduct：具体产品角色 具体产品角色是创建目标，所有创建的对象都充当这个角色的某个具体类的实例。

使用场景：

工厂类负责创建的对象比较少：由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。 客户端只知道传入工厂类的参数，对于如何创建对象不关心：客户端既不需要关心创建细节，甚至连类名都不需要记住，只需要知道类型所对应的参数。

工厂方法模式

定义：工厂方法模式(Factory Method Pattern)又称为工厂模式，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它属于类创建型模式。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。

模式结构：

工厂方法模式包含如下角色：

• Product：抽象产品
• ConcreteProduct：具体产品
• Factory：抽象工厂
• ConcreteFactory：具体工厂

使用场景：

在以下情况下可以使用工厂方法模式：

一个类不知道它所需要的对象的类：在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建；客户端需要知道创建具体产品的工厂类。 一个类通过其子类来指定创建哪个对象：在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。 将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定，可将具体工厂类的类名存储在配置文件或数据库中。

结构型

适配器模式（Adapter）

​ 定义：将一个接口转换成客户希望的另一个接口，适配器模式使接口不兼容的那些类可以一起工作，其别名为包装器。适配器模式即可以作为类结构型模式，也可以作为对象结构型模式。

​ 模式结构：

Target:目标抽象类；Adapter:适配器类；Adaptee:适配者类；Client:客户类

使用场景：系统需要复用现有类，而该类不符合系统的需求； 想要建立一个可重复使用类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。

外观模式（Facade）

​ 定义：外观模式(Facade Pattern)：外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。外观模式又称为门面模式，它是一种对象结构型模式。

​ 模式结构：

Facade: 外观角色

SubSystem:子系统角色

桥接模式（Bridge）

​ 定义：桥接模式(Bridge Pattern)：将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式

​ 模式结构：

桥接模式包含如下角色：

• Abstraction：抽象类
• RefinedAbstraction：扩充抽象类
• Implementor：实现类接口
• ConcreteImplementor：具体实现类

享元模式

定义：享元模式——运用共享技术有效地支持大量细粒度的对象。享元模式可以避免大量相似类的开销，在软件开发中如果需要生成大量细粒度的类实例来表示数据，如果这些实例除了几个参数外基本上都是相同的，这时候就可以使用享元模式来大幅度减少需要实例化类的数量。如果能把这些参数（指的这些类实例不同的参数）移动类实例外面，在方法调用时将他们传递进来，这样就可以通过共享大幅度地减少单个实例的数目。（这个也是享元模式的实现要领）,然而我们把类实例外面的参数称为享元对象的外部状态，把在享元对象内部定义称为内部状态。具体享元对象的内部状态与外部状态的定义为：

内部状态：在享元对象的内部并且不会随着环境的改变而改变的共享部分

外部状态：随环境改变而改变的，不可以共享的状态。

模式结构：

享元模式包含如下角色：

• Flyweight: 抽象享元类
• ConcreteFlyweight: 具体享元类
• UnsharedConcreteFlyweight: 非共享具体享元类（非必要）
• FlyweightFactory: 享元工厂类

组合模式（Composite）

定义

组合模式允许你将对象组合成树形结构来表现”部分-整体“的层次结构，使得客户以一致的方式处理单个对象以及对象的组合。下面我们用绘制的例子来详细介绍组合模式，图形可以由一些基本图形元素组成（如直线，圆等），也可以由一些复杂图形组成（由基本图形元素组合而成），为了使客户对基本图形和复杂图形的调用保持一致，我们使用组合模式来达到整个目的。

组合模式实现的最关键的地方是——简单对象和复合对象必须实现相同的接口。这就是组合模式能够将组合对象和简单对象进行一致处理的原因。

模式结构：

抽象构件（Component）角色：这是一个抽象角色，上面实现中Graphics充当这个角色，它给参加组合的对象定义出了公共的接口及默认行为，可以用来管理所有的子对象（在透明式的组合模式是这样的）。在安全式的组合模式里，构件角色并不定义出管理子对象的方法，这一定义由树枝结构对象给出。

树叶构件（Leaf）角色：树叶对象时没有下级子对象的对象，上面实现中Line和Circle充当这个角色，定义出参加组合的原始对象的行为

树枝构件（Composite）角色：代表参加组合的有下级子对象的对象，上面实现中ComplexGraphics充当这个角色，树枝对象给出所有管理子对象的方法实现，如Add、Remove等。

使用场景：

需要表示一个对象整体或部分的层次结构。

希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。

行为型

策略模式（Strategy）

​ 定义：策略模式是针对一组算法，将每个算法封装到具有公共接口的独立的类中，从而使它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。

策略模式包含如下角色：

• Context: 环境类
• Strategy: 抽象策略类
• ConcreteStrategy: 具体策略类

设计思想：策略模式体现两个基本的面向对象的设计思想：封装变化和面向接口编程。

中介者模式（Mediator）

​ 定义：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

中介者模式包含如下角色：

• Mediator: 抽象中介者
• ConcreteMediator: 具体中介者
• Colleague: 抽象同事类
• ConcreteColleague: 具体同事类

观察者模式（Observer）

​ 定义：观察者模式(Observer Pattern)：定义对象间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式又叫做发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。

​ 模式动机：建立一种对象与对象之间的依赖关系，一个对象发生改变时将自动通知其他对象，其他对象将相应做出反应。在此，发生改变的对象称为观察目标，而被通知的对象称为观察者，一个观察目标可以对应多个观察者，而且这些观察者之间没有相互联系，可以根据需要增加和删除观察者，使得系统更易于扩展，这就是观察者模式的模式动机。

​ 模式结构：

观察者模式包含如下角色：

• Subject: 目标
• ConcreteSubject: 具体目标
• Observer: 观察者
• ConcreteObserver: 具体观察者

模板方法（Template Method）

定义：

模板方法模式——在一个抽象类中定义一个操作中的算法骨架（对应于生活中的大家下载的模板），而将一些步骤延迟到子类中去实现（对应于我们根据自己的情况向模板填充内容）。模板方法使得子类可以不改变一个算法的结构前提下，重新定义算法的某些特定步骤，模板方法模式把不变行为搬到超类中，从而去除了子类中的重复代码。

模板方法模式中涉及了两个角色：

抽象模板角色：定义了一个或多个抽象操作，以便让子类实现，这些抽象操作称为基本操作。 具体模板角色：实现父类所定义的一个或多个抽象方法。

责任链模式（ChainOfRepository）

定义： 　责任链模式指的是——某个请求需要多个对象进行处理，从而避免请求的发送者和接收之间的耦合关系。将这些对象连成一条链子，并沿着这条链子传递该请求，直到有对象处理它为止。 模式结构 　主要涉及两个角色： 抽象处理者角色（Handler）：定义出一个处理请求的接口。这个接口通常由接口或抽象类来实现。 具体处理者角色（ConcreteHandler）：具体处理者接受到请求后，可以选择将该请求处理掉，或者将请求传给下一个处理者。因此，每个具体处理者需要保存下一个处理者的引用，以便把请求传递下去。

访问者模式（Vistor）

定义 　访问者模式是封装一些施加于某种数据结构之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构则可以保存不变。访问者模式适用于数据结构相对稳定的系统， 它把数据结构和作用于数据结构之上的操作之间的耦合度降低，使得操作集合可以相对自由地改变。 　　数据结构的每一个节点都可以接受一个访问者的调用，此节点向访问者对象传入节点对象，而访问者对象则反过来执行节点对象的操作。这样的过程叫做“双重分派”。节点调用访问者，将它自己传入，访问者则将某算法针对此节点执行。

访问者模式是一种将数据操作和数据结构分离的设计模式。

使用场景： 对象结构比较稳定，但经常需要在此对象结构上定义新的操作。 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免这些操作“污染”这些对象的类，也不希望在增加新操作时修改这些类。

模式结构： 抽象访问者角色（Vistor）:声明一个或者多个访问操作，使得所有具体访问者必须实现的接口。 具体访问者角色（ConcreteVistor）：实现抽象访问者角色中所有声明的接口。 抽象节点角色（Element）：声明一个接受操作，接受一个访问者对象作为参数。 具体节点角色（ConcreteElement）：实现抽象元素所规定的接受操作。 结构对象角色（ObjectStructure）：节点的容器，可以包含多个不同类或接口的容器。

备忘录模式（Memento）

定义 在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可以把该对象恢复到原先的状态。 模式结构 备忘录模式中主要有三类角色： 发起人角色：记录当前时刻的内部状态，负责创建和恢复备忘录数据。 备忘录角色：负责存储发起人对象的内部状态，在进行恢复时提供给发起人需要的状态。 管理者角色：负责保存备忘录对象。

命令模式（Command）

定义

命令模式属于对象的行为型模式。命令模式是把一个操作或者行为抽象为一个对象中，通过对命令的抽象化来使得发出命令的责任和执行命令的责任分隔开。命令模式的实现可以提供命令的撤销和恢复功能

模式结构

从命令模式的结构图可以看出，它涉及到五个角色，它们分别是：

• 客户角色：发出一个具体的命令并确定其接受者。
• 命令角色：声明了一个给所有具体命令类实现的抽象接口
• 具体命令角色：定义了一个接受者和行为的弱耦合，负责调用接受者的相应方法。
• 请求者角色：负责调用命令对象执行命令。
• 接受者角色：负责具体行为的执行。