设计模式视频
一、六大设计原则
1、单一职责
一个方法尽可能做一件事情
单一职责原则（Single Responsibility Principle，SRP）
2、接口隔离原则
尽量依赖最小的接口
六大设计模式原则-接口隔离原则
3、依赖倒置原则：
高层模块不应该依赖低层模块（基础模块），两者都应该依赖其抽象，传递的是抽象
抽象不应该依赖细节
细节应该依赖抽象
依赖倒置原则
4、里氏替换原则
继承必须确保超类所拥有的性质在子类中仍然成立（其阐述了有关继承的一些原则）
七大原则——里氏替换原则
里氏替换原则
5、开闭原则
一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)
六大原则之开闭原则
6、迪米特法则
一个对象应该对其他对象有最少的了解，所以迪米特法则又叫做最少知识原则
六大设计模式原则-迪米特法则
二、23种设计模式（GOF）
设计模式可分为三种类型，创建型模式、结构型模式和行为型模式
创建型模式（5种）
- 抽象工厂模式(Abstract Factory)
- 建造者模式(Builder)
- 工厂方法模式(Factory Method)
- 原型模式(Prototype)
- 单例模式(Singleton)
单例模式
- 单例类只能有一个实例。
- 单例类必须自己创建自己的唯一实例。
- 单例类必须给所有其他对象提供这一实例
JAVA设计模式之单例模式
简单工厂、工厂方法模式、抽象工厂模式
简单工厂模式
// 简单工厂核心类
class ShapeFactory {
public static Shape createShape(String des) {
switch (des) {
case "t":
return new Triggle();
case "c":
return new Circle();
case "r":
return new Rectangle();
}
return null;
}
}由一个工厂对象（ShapeFactory中createShape方法）决定创建出哪一种产品类的实例。
工厂方法模式
//日志记录器工厂接口：抽象工厂LogFactory
abstract class LogFactory {
public abstract Log createLog();
}
//文件日志记录器工厂类：具体工厂FileLogFactory
class FileLogFactory extends LogFactory {
@Override
public Log createLog() {
System.out.println("使用文件工厂");
return new FileLog();
}
}
//数据库日志记录器工厂类：具体工厂DatabaseLogFactory
class DatabaseLogFactory extends LogFactory {
@Override
public Log createLog() {
System.out.println("使用数据库工厂");
return new DatabaseLog();
}
}工厂方法模式把简单工厂进行了拆分，由原来根据条件集中创建，分散到创建工厂子类（FileLogFactory、DatabaseLogFactory）中进行创建。把对象的实例化推迟到子类。
抽象工厂模式
//数据库工厂接口：抽象工厂DBFactory
interface DBFactory{
public Connection createConnection();
public Statement createStatement();
}
//Oracle数据库工厂：具体工厂OracleFactory
class OracleFactory implements DBFactory{
@Override
public Connection createConnection() {
return new OracleConnection();
}
@Override
public Statement createStatement() {
return new OracleStatement();
}
}
//MySQL数据库工厂：具体工厂MySQLFactory
class MySQLFactory implements DBFactory{
@Override
public Connection createConnection() {
return new MySQLConnection();
}
@Override
public Statement createStatement() {
return new MySQLStatement();
}
}
//客户端测试类
public class lab1_3 {
public static void main(String[] args) {
try {
DBFactory factory;
Connection connection;
Statement statement;
factory = new MySQLFactory();
connection = factory.createConnection();
connection.connect();
statement = factory.createStatement();
statement.state();
} catch (Exception e) {
System.out.println(e.getMessage());
}
}
}抽象工厂模式可以将简单工厂模式和工厂方法模式进行整合。其创建不再是一个对象，而是一组相关或相互依赖的对象（OracleFactory、MySQLFactory）。
三大工厂模式（简单工厂、工厂方法、抽象工厂）
抽象工厂模式-Abstract Factory Pattern
原型模式
在实际项目中，原型模式很少单独出现，一般是和工厂方法模式一起出现，通过clone的方法创建一个对象，然后由工厂方法提供给调用者。原型模式已经与Java融为一体，大家可以随手拿来使用。
原型模式(Prototype Pattern)
建造者模式
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
四个角色：Product（产品角色），Builder（抽象建造者），ConcreteBuilder（具体建造者），Director（指挥者）
建造者模式适用场景 :
- 结构复杂 : 对象 有 非常复杂的内部结构 , 有很多属性 ;当一个类的构造函数参数个数超过4个，而且这些参数有些是可选的参数，考虑使用构造者模式。
- 分离创建和使用 :
建造者模式详解
【设计模式】建造者模式 ( 简介 | 适用场景 | 优缺点 | 代码示例 )
StringBuilder构建String的一个示例：
public final class StringBuilder extends AbstractStringBuilder implements java.io.Serializable, CharSequence {
public StringBuilder() {
super(16);
}
public java.lang.StringBuilder append(Object obj) {
return append(String.valueOf(obj));
}
public java.lang.StringBuilder append(String str) {
super.append(str);
return this;
}
public java.lang.StringBuilder append(boolean b) {
super.append(b);
return this;
}
public java.lang.StringBuilder append(char c) {
super.append(c);
return this;
}
public java.lang.StringBuilder append(int i) {
super.append(i);
return this;
}
// ... 其它操作字符串的实现
public String toString() {
return new String(value, 0, count);
}
}结构型模式（7种）
- 适配器模式(Adapter)
- 桥接模式(Bridge)
- 组合模式(Composite)
- 装饰模式(Decorator)
- 外观模式(Facade)
- 享元模式(Flyweight)
- 代理模式(Proxy)
适配器模式
将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的哪些类可以一起工作。
适配器角色：
- 目标角色（target）：这是客户锁期待的接口。目标可以是具体的或抽象的类，也可以是接口
- 适配者角色（adaptee）：已有接口，但是和客户器期待的接口不兼容。
- 适配器角色（adapter）：将已有接口转换成目标接口。定义默认实现，使用时只实现需要的接口
适配器模式有分三类：
- 类适配器模式（class adapter pattern），adapter extends adaptee implements target
- 对象适配器模式（object adapter pattern），adapter implements target，并且包含adaptee
- 缺省适配器模式（default adapter pattern），也叫默认适配器模式、接口适配器模式
适配器模式（Adapter Pattern）
适配器模式
优点（总结）：
类适配器模式（class adapter pattern）：
由于适配器adapter类是适配者adaptee类的子类，因此可以在适配器类中置换一些适配者的方法，即Override（重写），使得适配器的灵活性更强。
对象适配器模式（object adapter pattern）：
一个对象适配器可以把多个不同的适配者adaptee适配到一个目标，也就是说，同一个适配器可以将适配者类和它的子类都适配到目标接口。
桥接模式
将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
主要角色：
- 抽象化（Abstraction）角色：定义抽象类，并包含一个对实现化对象的引用。提供高层控制逻辑， 依赖于完成底层实际工作的实现对象。
- 扩展抽象化（Refined Abstraction）角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用实现化角色中的业务方法。
- 实现化（Implementor）角色：定义实现化角色的接口，供扩展抽象化角色调用。
- 具体实现化（Concrete Implementor）角色：给出实现化角色接口的具体实现。
- 客户端（Client）：仅关心如何与抽象部分合作。但是，客户端需要将抽象对象与一个实现对象连接起来。
适用场景：
- 当一个对象有多个变化因素的时候，考虑依赖于抽象的实现，而不是具体的实现。如手机品牌有2种变化因素，一个是品牌，一个是功能。
- 当多个变化因素在多个对象间共享时，考虑将这部分变化的部分抽象出来再聚合/合成进来，如通讯录和游戏，其实是可以共享的。
- 当我们考虑一个对象的多个变化因素可以动态变化的时候，考虑使用桥接模式，如上面例子中的手机品牌是变化的，手机的功能也是变化的，所以将他们分离出来，独立的变化。
桥接模式
桥接模式（Bridge）
装饰模式
动态地给一个对象添加一些额外的功能，比生成子类要灵活。
使用场景：
需要透明且动态地拓展类的功能的场景。
角色：
- 抽象组件Component类。
- 组件具体实现ConcreteComponent类。也是被装饰的对象。
- 抽象装饰类Decorator，内部持有一个组件对象的引用，职责就是装饰ConcreteComponent类。之所以是抽象的，就是为了方便不同的装饰“风格”子类的自定义实现。
- 具体装饰类ConcreteDecorator。
装饰模式总结：
装饰模式动态地给一个对象添加一些额外的功能，相对于继承的方式，更加灵活。
装饰模式经常被误认为是代理模式。装饰模式是以对客户透明的方式扩展对象的功能，是继承关系的一个替代方案。而代理模式则是给一个对象提供一个代理对象，并由代理对象来控制原有对象的引用。
前者重在增加功能，后者重在对代理对象施加控制，不是对对象本身功能的增强。
设计模式——装饰模式详解
// FilterInputStream 装饰类，InputStream 为抽象组件
public class FilterInputStream extends InputStream {
protected volatile InputStream in;
// ...
}组合模式
组合模式又叫部分整体模式，是用于把一组相似的对象当作一个单一的对象。
使用场景：
当你发现需求中是用树形结构体现部分与整体层次关系的结构时，且你希望用户可以忽略整体和部分、组合对象和单个对象的不同，统一地使用组合结构中的所有对象时，就应该使用组合模式。
组合模式解决上面所说的两个问题：
1、部分与整体的层次关系表示为树形结构、
2、部分与整体的对象，是能让客户端能统一对待、不需区分的对象。
场景：树形菜单，文件、件夹的管文理。
角色
组合模式有三个基本部件： 即抽象部件、叶子部件、树枝部件，这三个部件组成的一颗树形结构。
- 抽象构件（Component）：叶子构件和容器构件继承的抽象类，包含叶子和容器的共有行为的声明，如业务方法，也可能包含管理叶子的方法。
- 叶子构件（Leaf）：树的叶结点，实现抽象构件的业务方法，对于容器特有的管理子结点的方法，可以使用空方法或者抛出异常处理。
- 树枝构件（Composite）：树的叶结点，实现抽象构件的业务方法，对于容器特有的管理子结点的方法，可以使用空方法或者抛出异常处理。
组合模式的两种分类
组合模式根据代码实现的不同分为透明组合模式和安全组合模式
设计模式——组合模式
外观模式
外观（Facade）模式又叫作门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。
应用场景
通常在以下情况下可以考虑使用外观模式。
- 对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
- 当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。
- 当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。
23种设计模式之外观模式
享元模式
享元模式（Flyweight pattern）又叫轻量级模式，是对象池的一种标签。类似线程池，线程池可以避免不停的创建和销毁对象，消耗性能。享元模式可以减少对象数量，其宗旨是共享细粒度对象，将多个对同一对象的访问集中起来。
适用场景
- 系统中有大量对象
- 这些对象消耗大量内存
- 这些对象的状态大部分可以外部化。
- 这些对象可以按照内蕴状态分为很多组，当把外蕴对象从对象中剔除出来时，每一组对象都可以用一个对象来代替
- 系统不依赖于这些对象身份，这些对象是不可分辨的。
角色
- FlyWeight：抽象的享元角色，产品的抽象类，定义了对象的外部状态和内部状态的接口或实现
- ConcreteFlyWeight：具体的享元角色，产品的实现类，实现了抽象角色定义的相关业务
- UnSharedConcreteFlyWeight：不可共享的角色，一般不会出现在享元工厂中
- FlyWeightFactory：享元工厂类，内部提供一个池容器，储存ConcreteFlyWeight，同时提供从池中存取数据的操作
享元模式
享元模式
代理模式
代理模式是常见的设计模式之一，顾名思义，代理模式就是代理对象具备真实对象的功能，并代替真实对象完成相应操作，并能够在操作执行的前后，对操作进行增强处理。（为真实对象提供代理，然后供其他对象通过代理访问真实对象）
应用场景
- 中介隔离作用：在某些情况下，一个客户类不想或者不能直接引用一个委托对象，而代理类对象可以在客户类和委托对象之间起到中介的作用，其特征是代理类和委托类实现相同的接口。
- 开闭原则，增加功能：代理类除了是客户类和委托类的中介之外，我们还可以通过给代理类增加额外的功能来扩展委托类的功能，这样做我们只需要修改代理类而不需要再修改委托类，符合代码设计的开闭原则。代理类主要负责为委托类预处理消息、过滤消息、把消息转发给委托类，以及事后对返回结果的处理等。代理类本身并不真正实现服务，而是同过调用委托类的相关方法，来提供特定的服务。真正的业务功能还是由委托类来实现，但是可以在业务功能执行的前后加入一些公共的服务。例如我们想给项目加入缓存、日志这些功能，我们就可以使用代理类来完成，而没必要打开已经封装好的委托类
静态代理
一文搞懂代理模式
代理模式详细讲解
JDK代理接口，CGLIB代理子类
行为型模式（11种）
- 职责链模式(Chain of Responsibility)
- 命令模式(Command)
- 解释器模式(Interpreter)
- 迭代器模式(Iterator)
- 中介者模式(Mediator)
- 备忘录模式(Memento)
- 观察者模式(Observer)
- 状态模式(State)
- 策略模式(Strategy)
- 模板方法模式(Template Method)
- 访问者模式(Visitor)
模板方法模式
定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
Java设计模式—模板方法模式
C++设计模式-模板方法模式
命令模式
命令(Command)模式又叫作动作(Action)模式或事务(Transaction)模式，是一种对象的行为模式。将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
应用场景
- 如果需要抽象出需要执行的动作，并参数化这些对象，可以选用命令模式。将这些需要执行的动作抽象成为命令，然后实现命令的参数化配置。
- 如果需要在不同的时刻指定、排列和执行请求，可以选用命令模式。将这些请求封装成为命令对象，然后实现将请求队列化。
- 如果需要支持取消操作，可以选用命令模式，通过管理命令对象，能很容易地实现命令的恢复和重做功能。
- 如果需要支持当系统崩溃时，能将系统的操作功能重新执行一遍，可以选用命令模式。将这些操作功能的请求封装成命令对象，然后实现日志命令，就可以在系统恢复以后，通过日志获取命令列表，从而重新执行一遍功能。
- 在需要事务的系统中，可以选用命令模式。命令模式提供了对事务进行建模的方法。命令模式有一个别名就是Transaction。
角色
- 抽象命令(Command)角色：一般定义为接口，用来定义执行命令的接口。
- 具体命令(ConcreteCommand)角色：通常会持有接收者对象，并调用接收者对象的相应功能来完成命令要执行的操作。
- 接收者(Receiver)角色：真正执行命令的对象。任何类都可能成为接收者，只要它能够实现命令要求实现的相应功能。
- 调用者(Invoker)角色：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
- 客户端(Client)角色：创建具体的命令对象，并且设置命令对象的接收者。
命令模式（行为型）
从零开始学设计模式(二十二)：命令模式（Command Pattern）
- 更松散的耦合： 命令模式使得发起命令的对象——客户端，和具体实现命令的对象——接收者对象完全解耦，也就是说发起命令的对象完全不知道具体实现对象是谁，也不知道如何实现。
- 更动态的控制：命令模式把请求封装起来，可以动态地对它进行参数化、队列化和日志化等操作，从而使得系统更灵活。
- 很自然的复合命令：命令模式中的命令对象能够很容易地组合成复合命令，如宏命令，从而使系统操作更简单，功能更强大。
- 更好的扩展性： 由于发起命令的对象和具体的实现完全解耦，因此扩展新的命令就很容易，只需要实现新的命令对象，然后在装配的时候，把具体的实现对象设置到命令对象中，然后就可以使用这个命令对象，已有的实现完全不用变化。
访问者模式
封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
角色
- 抽象访问者(Visitor)角色：声明了一个或者多个方法操作，形成所有的具体访问者角色必须实现的接口。
- 具体访问者(ConcreteVisitor)角色：实现抽象访问者所声明的接口，也就是抽象访问者所声明的各个访问操作【VisitorA，VisitorB】。
- 抽象节点(Node)角色：声明一个接受操作，接受一个访问者对象作为一个参数。
- 具体节点(ConcreteNode)角色：实现了抽象节点所规定的接受操作【NodeA，NodeB】。
- 结构对象(ObjectStructure)角色：有如下的责任，可以遍历结构中的所有元素；如果需要，提供一个高层次的接口让访问者对象可以访问每一个元素；如果需要，可以设计成一个复合对象或者一个聚集，如List或Set。
【设计模式】访问者模式
平时使用不多
迭代器模式
ArrayList，Vector（容器）
Java设计模式之行为型：迭代器模式
迭代器模式
观察者模式
观察者模式又叫作发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependent）模式
组成：
- 抽象主题（ISubject）：指被观察的对象（IObservable）
- 具体主题（ConcreteSubject）：具体被观察者
- 抽象观察者（IObserver）：定义响应通知的更新方法
- 具体观察者（ConcreteObserver）：当得到状态更新的通知时，会自动做出响应
/**
* 主题：被观察者
*/
public interface ISubject {
void notify(String event);
boolean register(IObservable observable);
boolean remove(IObservable observable);
}
public class ConcreteSubject implements ISubject {
private List<IObservable> observables = new ArrayList<>();
@Override
public boolean register(IObservable observable) {
return !this.observables.contains(observable) && this.observables.add(observable);
}
@Override
public boolean remove(IObservable observable) {
return this.observables.remove(observable);
}
@Override
public void notify(String event) {
for (IObservable observable : this.observables) {
observable.handler(event);
}
}
}
//======================================================== 观察者
/**
* 观察者：监听被观察者的变化
*/
public interface IObservable {
void handler(String event);
}
public class ConcreteObserverA implements IObservable {
@Override
public void handler(String event) {
System.out.println("concrete observer A: " + event);
}
}
public class ConcreteObserverB implements IObservable {
@Override
public void handler(String event) {
System.out.println("concrete observer B: " + event);
}
}
//======================================================== 测试
@Test
public void test() {
ISubject subject = new ConcreteSubject();
subject.register(new ConcreteObserverA());
subject.register(new ConcreteObserverB());
subject.notify("test");
}中介者模式
又叫调停模式，定义一个中介角色来封装一系列对象之间的交互，使原有对象之间的耦合松散，且可以独立地改变它们之间的交互。
主要角色
- 抽象中介者接口（Mediator）角色：它是中介者的接口，提供了同事对象注册与转发同事对象信息的抽象方法（通信）。
- 具体中介者（ConcreteMediator）角色：实现中介者接口， 是抽象中介者的子类 ，定义一个 List 来管理同事对象，协调各个同事角色之间的交互关系， 维持了对各个同事对象的引用 ，因此它依赖于同事角色。
- 抽象同事类（Colleague）角色： 它定义各个同事类公有的方法，并声明了一些抽象方法来供子类实现，同时它维持了一个对抽象中介者类的引用，其子类可以通过该引用来与中介者通信。
- 具体同事类（Concrete Colleague）角色： 它是抽象同事类的子类；每一个同事对象在需要和其他同事对象通信时，先与中介者通信，通过中介者来间接完成与其他同事类的通信；在具体同事类中实现了在抽象同事类中声明的抽象方法。
设计模式之中介者模式详解
备忘录模式
允许在不暴露对象实现细节的情况下保存和恢复对象之前的状态。
- Memento:备忘录。主要用来存储原发器对象的内部状态，但是具体需要存储哪些数据是由原发器对象来决定的。另外备忘录应该只能由原发器对象来访问它内部的数据，原发器外部的对象不应该访问到备忘录对象的内部数据。
- Originator:原发器。使用备忘录来保存某个时刻原发器自身的状态，也可以使用备忘录来恢复内部状态。
- Caretaker:备忘录管理者，或者称为备忘录负责人。主要负责保存备忘录对象，但是不能对备忘录对象的内容进行操作或检查。
备忘录模式
解释器模式
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
解释器模式（Interpreter Pattern）提供了评估语言的语法或表达式的方式，它属于行为型模式。这种模式实现了一个表达式接口，该接口解释一个特定的上下文。这种模式被用在 SQL 解析、符号处理引擎等。
结构
解释器模式包含如下角色：
- AbstrExpression: 抽象表达式
- TerminalExpression: 终结符表达式
- NonterminalExpression: 非终结符表达式
- Context: 环境类：包含解释器之外的一些全局信息
解释器模式
状态模式
对有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为。
主要角色
- 环境类（Context）角色：也称为上下文，它定义了客户端需要的接口，内部维护一个当前状态，并负责具体状态的切换。
- 抽象状态（State）角色：定义一个接口，用以封装环境对象中的特定状态所对应的行为，可以有一个或多个行为。
- 具体状态（Concrete State）角色：实现抽象状态所对应的行为，并且在需要的情况下进行状态切换。
策略模式
策略模式是一种行为型模式，它将对象和行为分开，将行为定义为 一个行为接口 和 具体行为的实现。策略模式最大的特点是行为的变化，行为之间可以相互替换。每个if判断都可以理解为就是一个策略。本模式使得算法可独立于使用它的用户而变化
Java设计模式——策略模式
Java设计模式——策略模式
策略模式
职责链模式
为了避免请求发送者与多个请求处理者耦合在一起，于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止
角色
- 抽象处理者（Handler）角色：定义一个处理请求的接口，包含抽象处理方法和一个后继连接。
- 具体处理者（Concrete Handler）角色：实现抽象处理者的处理方法，判断能否处理本次请求，如果可以处理请求则处理，否则将该请求转给它的后继者。
- 客户类（Client）角色：创建处理链，并向链头的具体处理者对象提交请求，它不关心处理细节和请求的传递过程。
职责链模式
总结
设计模式中的创建型、结构型、行为型有什么区别和联系？
代理模式和装饰模式的区别
