一.常见的设计模式
1.创建型模式(Creational Patterns):
1.工厂模式(Factory Pattern)
2.抽象工厂模式(Abstract Factory Pattern)
3.单例模式(Singleton Pattern)
4.原型模式(Prototype Pattern)
5.建造者模式(Builder Pattern)
2.结构型模式(Structural Patterns):
1.适配器模式(Adapter Pattern)
2.桥接模式(Bridge Pattern)
3.组合模式(Composite Pattern)
4.装饰模式(Decorator Pattern)
5.外观模式(Facade Pattern)
6.享元模式(Flyweight Pattern)
7.代理模式(Proxy Pattern)
3.行为型模式(Behavioral Patterns):
1.责任链模式(Chain of Responsibility Pattern)
2.命令模式(Command Pattern)
3.解释器模式(Interpreter Pattern)
4.迭代器模式(Iterator Pattern)
5.中介者模式(Mediator Pattern)
6.备忘录模式(Memento Pattern)
7.观察者模式(Observer Pattern)
8.状态模式(State Pattern)
9.策略模式(Strategy Pattern)
10.模板方法模式(Template Method Pattern)
11.访问者模式(Visitor Pattern)
二.基本概念
1.工厂模式(Factory Pattern):通过定义一个创建对象的接口,由子类决定实例化哪个具体类。适用于需要创建对象,但不希望客户端直接与具体类耦合的场景。
2.抽象工厂模式(Abstract Factory Pattern):提供一个接口用于创建相关或依赖对象的家族,而不需要指定具体的类。适用于需要创建一组相关对象的场景,且希望将创建逻辑与使用者分离。
3.单例模式(Singleton Pattern):保证一个类只有一个实例,并提供全局访问点。适用于需要全局唯一实例的场景,如日志记录器、数据库连接等。
4.原型模式(Prototype Pattern):通过复制现有对象来创建新对象,避免了重复构造过程,提高了对象创建的效率。
5.建造者模式(Builder Pattern):将一个复杂对象的构建过程与其表示分离,通过一步一步构建的方式创建对象。适用于构建复杂对象,且构建过程需要灵活配置的场景。
6.适配器模式(Adapter Pattern):将一个类的接口转换成客户端所期望的另一个接口。适用于需要将不兼容接口转换为兼容接口的场景。
7.桥接模式(Bridge Pattern):将抽象部分与其具体实现部分分离,使它们可以独立地变化。适用于存在多种变化维度的场景,可以提高系统的可扩展性。
8.组合模式(Composite Pattern):将对象组合成树状结构,以表示部分-整体的层次结构。适用于需要表示对象的整体-部分层次结构,并且希望对整体和部分都进行一致的操作。
9.装饰模式(Decorator Pattern):动态地给对象添加额外的职责,而不影响其原始类。适用于需要在不修改原始类的情况下,给对象添加功能或职责的场景。
10.外观模式(Facade Pattern):为复杂子系统提供一个简单统一的接口,隐藏了子系统的复杂性,使其易于使用。适用于需要简化对外接口的场景。
11.享元模式(Flyweight Pattern):共享对象以减少内存使用和提高性能。适用于需要创建大量相似对象的场景,通过共享对象来节省内存。
12.代理模式(Proxy Pattern):为其他对象提供一个代理以控制对其的访问。适用于需要在访问对象时添加额外的控制逻辑的场景,如延迟加载、权限控制等。
13.责任链模式(Chain of Responsibility Pattern):将请求的发送者和接收者解耦,通过一条链传递请求,直到有一个对象能够处理它为止。适用于需要动态确定处理请求的对象集合的场景。
14.命令模式(Command Pattern):将请求封装成对象,以便在不同的请求发送者和接收者之间进行解耦。适用于需要将请求参数化、排队或记录请求操作的场景。
15.解释器模式(Interpreter Pattern):定义了一个语言的文法,并定义该语言的解释器。适用于需要解释和执行一些特定规则或语言的场景。
16.迭代器模式(Iterator Pattern):提供一种顺序访问聚合对象中各个元素的方式,而不暴露其内部表示。适用于需要遍历聚合对象并访问其中元素的场景。
17.中介者模式(Mediator Pattern):通过引入一个中介对象,将系统中多个对象之间的交互进行解耦。适用于需要集中管理多个对象之间交互的场景。
18.备忘录模式(Memento Pattern):在不违反封装原则的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。适用于需要保存和恢复对象状态的场景。
19.观察者模式(Observer Pattern):定义了一种一对多的依赖关系,使得多个观察者对象同时监听一个主题对象的状态变化。适用于需要实现对象间的松耦合、一对多的依赖关系的场景。
20.状态模式(State Pattern):允许对象在其内部状态发生改变时改变其行为。适用于对象行为随状态改变而改变的场景,可以避免使用大量的条件判断语句。
21.策略模式(Strategy Pattern):定义了一系列的算法,并将其封装起来,使其可以相互替换。适用于需要在运行时根据不同情况选择不同算法的场景。
22.模板方法模式(Template Method Pattern):定义了一个算法的骨架,将某些步骤延迟到子类中实现。适用于具有相似算法结构,但其中某些步骤有所不同的场景。
23.访问者模式(Visitor Pattern):封装一些作用于某种数据结构中的各元素的操作,使其可以在不改变元素类的前提下,定义新的操作。适用于需要对数据结构中的元素进行不同操作的场景
三.特点与适用场景
设计模式 |
特点 |
适用场景 |
工厂模式(Factory Pattern) | 封装了对象的创建过程,隐藏了具体实现,通过工厂方法来创建对象。 | - 当客户端需要创建对象,但不需要知道具体实现类时 - 当创建对象的过程比较复杂,需要封装起来以便复用和管理时<br>- 当需要使用相同的接口创建一族相关对象时 |
抽象工厂模式(Abstract Factory Pattern) | 提供了一个接口用于创建相关或依赖对象的家族,不需要指定具体的类。 | - 当有多个相关的产品系列需要创建时 - 当系统需要独立于产品的创建、组合和表示时 |
单例模式(Singleton Pattern) | 保证一个类只有一个实例,并提供全局访问点。 | - 当需要确保一个类只有一个实例时 - 当全局访问点能够提供对该实例的访问时 |
原型模式(Prototype Pattern) | 通过复制现有对象来创建新对象,避免了重复的构造过程。 | - 当对象的创建过程较为复杂,且需要避免重复构造时<br>- 当需要动态添加或删除对象时 |
建造者模式(Builder Pattern) | 将一个复杂对象的构建过程与其表示分离,通过一步一步构建的方式创建对象。 | - 当创建复杂对象的构造过程比较繁琐且多样化时 - 当需要创建多个相似对象时 |
适配器模式(Adapter Pattern) | 将一个类的接口转换成客户端所期望的另一个接口。 | - 当需要将已存在的类与其他类协同工作时 - 当需要使用某个已存在的类,但其接口与需求不匹配时 |
桥接模式(Bridge Pattern) | 将抽象部分与其具体实现部分分离,使它们可以独立地变化。 | - 当需要将抽象和实现部分分离,以便独立地变化和扩展时<br>- 当需要在多个维度上进行扩展时 |
组合模式(Composite Pattern) | 将对象组合成树状结构,以表示部分-整体的层次结构。 | - 当需要表示对象的整体-部分层次结构,并希望对整体和部分都进行一致的操作时 - 当需要忽略对象与对象集合的不同,统一对待时 |
装饰模式(Decorator Pattern) | 动态地给对象添加额外的职责,而不影响其原始类。 | - 当需要在不修改原始类的情况下,给对象添加功能或职责时<br>- 当需要通过多个对象进行功能组合时 |
外观模式(Facade Pattern) | 为复杂子系统提供一个简单统一的接口,隐藏了子系统的复杂性,使其易于使用。 | - 当需要简化对外接口的场景 - 当需要对复杂子系统进行解耦,提高系统的灵活性和可维护性时 |
享元模式(Flyweight Pattern) | 共享对象以减少内存使用和提高性能。 | - 当需要创建大量相似对象时,并且对象的状态可在外部环境中共享和复用时 |
代理模式(Proxy Pattern) | 为其他对象提供一个代理以控制对其的访问。 | - 当需要在访问对象时添加额外的控制逻辑时 - 当需要延迟创建或访问对象时 |
责任链模式(Chain of Responsibility Pattern) | 将请求的发送者和接收者解耦,通过一条链传递请求,直到有一个对象能够处理它。 | - 当需要动态确定处理请求的对象集合的场景 - 当需要按顺序处理请求,但不明确知道哪个对象能处理请求时 |
命令模式(Command Pattern) | 将请求封装成对象,以便在不同的请求发送者和接收者之间进行解耦。 | - 当需要将请求参数化、排队或记录请求操作的场景 - 当需要支持撤销和重做操作时 |
解释器模式(Interpreter Pattern) | 定义了一个语言的文法,并定义该语言的解释器。 | - 当需要解释和执行一些特定规则或语言的场景时 |
迭代器模式(Iterator Pattern) | 提供一种顺序访问聚合对象中各个元素的方式,而不暴露其内部表示。 | - 当需要遍历聚合对象并访问其中元素的场景时 - 当需要对不同聚合对象提供统一的访问方式时 |
中介者模式(Mediator Pattern) | 通过引入一个中介对象,将系统中多个对象之间的交互进行解耦。 | - 当需要集中管理多个对象之间交互的场景时 - 当系统中对象之间的交互逻辑复杂且紧密耦合时 |
备忘录模式(Memento Pattern) | 在不违反封装原则的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。 | - 当需要保存和恢复对象状态的场景 - 当需要实现撤销和恢复功能时 |
观察者模式(Observer Pattern) | 定义了一种一对多的依赖关系,使得多个观察者对象同时监听一个主题对象的状态变化。 | - 当需要实现对象间的松耦合、一对多的依赖关系的场景时 - 当一个对象状态变化需要通知其他对象时 |
状态模式(State Pattern) | 允许对象在其内部状态发生改变时改变其行为。 | - 当对象行为随状态改变而改变的场景 - 当需要避免使用大量的条件判断语句时 |
策略模式(Strategy Pattern) | 定义了一系列的算法,并将其封装起来,使其可以相互替换。 | - 当需要在运行时根据不同情况选择不同算法的场景时 |
模板方法模式(Template Method Pattern) | 定义了一个算法的骨架,将某些步骤延迟到子类中实现。 | - 当具有相似算法结构,但其中某些步骤有所不同的场景时 - 当需要通过子类来扩展和实现算法的某些特定步骤时 |
访问者模式(Visitor Pattern) | 封装一些作用于某种数据结构中的各元素的操作,使其可以在不改变元素类的前提下,定义新的操作。 | - 当需要对数据结构中的元素进行不同操作,且不希望改变元素类的结构时 |