23种设计模式
一.简单介绍:
1. 创建型模式（Creational Patterns）
- 简单工厂模式（Simple Factory Pattern）
- 工厂方法模式（Factory Method Pattern）
- 抽象工厂模式（Abstract Factory Pattern）
- 单例模式（Singleton Pattern）
- 原型模式（Prototype Pattern）
- 建造者模式（Builder Pattern）
2. 结构型模式（Structural Patterns）
- 适配器模式（Adapter Pattern）
- 桥接模式（Bridge Pattern）
- 组合模式（Composite Pattern）
- 装饰器模式（Decorator Pattern）
- 外观模式（Facade Pattern）
- 享元模式（Flyweight Pattern）
- 代理模式（Proxy Pattern）
3. 行为型模式（Behavioral Patterns）
- 责任链模式（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）
1、抽象工厂模式是提供一个接口，用于创建相关或者依赖对象的家族，而不需要明确指定具体类。
2、建造模式是将一个复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的表示。
3、工厂方法模式定义一个创建对象的接口，让子类决定实例化那个类。
4、原型模式是用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。
5、单例模式，它的定义就是确保某一个类只有一个实例，并且提供一个全局访问点。
6、外观模式提供了一个统一的接口，用来访问子系统中的一群接口。
7、适配器模式是将一个类的接口，转换成客户期望的另一个接口。
8、桥接模式是讲抽象部分和实现部分隔离开来，使得他们能够独立变化。
9、组合模式组合多个对象形成树形结构以表示“整体-部分”的结构层次。
10、装饰模式：动态的给对象添加新的功能。
11、享元模式就是运行共享技术有效地支持大量细粒度对象的复用。
12、代理模式就是给一个对象提供一个代理，并由代理对象控制对原对象的引用。
13、命令模式将请求封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。
14、解释器模式就是定义语言的文法，并且建立一个解释器来解释该语言中的句子。
15、访问者模式即在不改变数据结构的前提下，增加作用于一组对象元素的新功能。
16、迭代子模式是提供一种方法顺序访问一个聚合对象中的各个元素，而不暴露其内部的表示。
17、中介者模式就是用一个中介对象来封装一系列的对象交互。
18、备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态。
19、观察者模式定义了对象之间的一对多依赖关系。
20、状态模式就是允许对象在内部状态发生改变时改变它的行为。
21、策略模式就是定义了算法族，分别封装起来，让他们之前可以互相转换。
22、模板方法模式就是在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。
23、责任链模式是将请求的发送者和接收者解耦，使的多个对象都有处理这个请求的机会。
二.使用场景:
-
单例模式（Singleton）：
- 场景1：需要确保系统中只有一个实例，并提供对该实例的全局访问。
- 场景2：需要共享资源，例如数据库连接池或线程池。
- 场景3：需要对系统中的某个状态进行全局控制，例如全局配置信息。
-
工厂方法模式（Factory Method）：
- 场景1：希望通过子类来决定创建对象的具体类型。
- 场景2：需要将对象的创建与使用解耦。
- 场景3：希望通过扩展工厂类来添加新的产品。
-
抽象工厂模式（Abstract Factory）：
- 场景1：希望通过一组相关的工厂来创建一系列相互关联的对象。
- 场景2：需要隐藏具体产品的实现细节，只暴露抽象接口。
- 场景3：希望在运行时切换不同的产品簇。
-
建造者模式（Builder）：
- 场景1：需要创建复杂的对象，且创建过程需要多个步骤。
- 场景2：希望通过相同的构建过程创建不同的表示。
- 场景3：需要隔离复杂对象的创建和使用。
-
原型模式（Prototype）：
- 场景1：需要创建一个对象的多个副本，且副本的创建成本较高。
- 场景2：希望通过修改原型来创建新对象，而不是通过构造函数。
- 场景3：需要动态地添加和删除对象。
-
适配器模式（Adapter）：
- 场景1：需要将一个类的接口转换成客户端期望的接口。
- 场景2：希望复用已有的类，但其接口与要求不符。
- 场景3：需要与多个类或接口进行交互，但它们具有不同的接口。
-
桥接模式（Bridge）：
- 场景1：希望将抽象部分与实现部分分离，使它们可以独立地变化。
- 场景2：需要在多个维度上扩展一个类的功能。
- 场景3：希望在运行时切换不同的实现。
-
装饰器模式（Decorator）：
- 场景1：需要在不改变现有对象结构的情况下，动态地添加额外的功能。
- 场景2：希望通过组合来替代继承，以避免类爆炸。
- 场景3：需要对对象的功能进行扩展，但不适合使用子类继承的方式。
-
组合模式（Composite）：
- 场景1：希望以统一的方式处理单个对象和对象组合。
- 场景2：需要表示对象的部分-整体层次结构。
- 场景3：希望客户端对单个对象和组合对象保持一致的方式进行操作。
-
外观模式（Facade）：
- 场景1：希望为复杂子系统提供一个简化的接口。
- 场景2：需要将客户端与复杂的子系统解耦。
- 场景3：希望对外隐藏子系统的实现细节。
-
享元模式（Flyweight）：
- 场景1：需要创建大量相似对象，以节省内存和提高性能。
- 场景2：对象的大部分状态可以外部化，并且可以通过参数传递给对象。
- 场景3：希望共享对象以减少对象的数量。
-
代理模式（Proxy）：
- 场景1：需要在访问对象之前或之后执行额外的操作。
- 场景2：希望通过代理对象控制对真实对象的访问。
- 场景3：需要在远程对象上进行本地操作。
-
模板方法模式（Template Method）：
- 场景1：需要定义算法的框架，但允许子类为某些步骤提供具体实现。
- 场景2：希望通过子类来扩展算法的特定步骤。
- 场景3：需要在不改变算法结构的情况下重新定义算法的某些步骤。
-
策略模式（Strategy）：
- 场景1：希望在运行时选择算法的不同变体。
- 场景2：需要根据不同的条件应用不同的算法。
- 场景3：需要通过组合而不是继承来实现算法的变化。
-
命令模式（Command）：
- 场景1：需要将请求封装成对象，以支持撤销、重做或队列等操作。
- 场景2：需要将请求的发送者与接收者解耦。
- 场景3：需要支持对请求进行参数化。
-
观察者模式（Observer）：
- 场景1：当一个对象的状态发生变化时，需要通知其他对象。
- 场景2：需要建立对象之间的一对多依赖关系。
- 场景3：希望在不同的对象之间保持一致性。
-
迭代器模式（Iterator）：
- 场景1：需要按顺序访问集合对象的元素，而不暴露其内部实现。
- 场景2：需要提供一种通用的方式来遍历不同类型的集合。
- 场景3：希望对集合进行多种方式的遍历。
-
状态模式（State）：
- 场景1：当一个对象的行为取决于其内部状态，并且需要在运行时根据状态改变其行为时。
- 场景2：希望通过消除大型条件语句来简化复杂的状态机逻辑。
- 场景3：需要将状态转换逻辑封装在状态类中，以便于维护和扩展。
-
备忘录模式（Memento）：
- 场景1：需要保存和恢复对象的状态
- 场景2：需要实现撤销和重做功能
- 场景3：需要实现快照和恢复功能
- 解释器模式（Interpreter）：
- 场景1：需要定义一种语言的语法，并且希望能够解释和执行该语言的表达式。
- 场景2：需要实现一个简单的查询语言或规则引擎。
- 场景3：希望通过使用解释器来处理复杂的业务规则。
- 访问者模式（Visitor）：
- 场景1：需要对一个复杂的对象结构进行操作，而不暴露其内部结构。
- 场景2：希望在不改变对象结构的前提下，定义新的操作。
- 场景3：需要对不同类型的对象执行不同的操作，而不使用类型检查和类型转换。
- 中介者模式（Mediator）：
- 场景1：需要通过一个中介对象来协调一组对象之间的交互。
- 场景2：希望减少对象之间的直接耦合度。
- 场景3：需要集中管理一组对象之间的复杂交互逻辑。
- 责任链模式（Chain of Responsibility）：
- 场景1：需要根据不同的条件将请求传递给不同的处理者。
- 场景2：希望动态地指定处理请求的对象集合。
- 场景3：需要避免请求发送者和接收者之间的显式耦合。
公众号请关注 "果酱桑", 一起学习,一起进步!