设计模式可以大致分为以下几类：创建型模式、结构型模式和行为型模式。每一类设计模式都有其独特的特点和应用场景。下面我将对这三类设计模式进行详细说明，并介绍它们各自的应用场景。
创建型模式
创建型模式 关注对象的创建过程，它抽象了实例化过程，帮助我们在创建对象时无需直接使用 new 关键字，降低了系统的耦合度。
- 单例模式（Singleton Pattern）
- 描述：确保一个类只有一个实例，并提供一个全局访问点。
- 应用场景：当频繁实例化并且创建的对象消耗很多资源时，如数据库连接池、日志记录器等。
- 工厂模式（Factory Pattern）
- 描述：定义一个用于创建对象的接口，让子类决定实例化哪一个类。
- 应用场景：当创建对象时不想直接使用
new关键字，而是想将对象的创建与使用相分离时。
- 抽象工厂模式（Abstract Factory Pattern）
- 描述：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
- 应用场景：当需要创建的对象之间存在关联或依赖关系时，如UI工具包中的按钮、文本框等组件的创建。
- 建造者模式（Builder Pattern）
- 描述：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
- 应用场景：当需要创建一个复杂对象，该对象的构建过程允许有不同的表示时，如配置文件的生成、SQL语句的构造等。
- 原型模式（Prototype Pattern）
- 描述：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
- 应用场景：当创建对象的成本较大（如初始化需要占用较多资源）时，或者当需要频繁创建具有相同或相似状态的对象时。
结构型模式
结构型模式 关注类和对象的组合，它采用继承以外的方法来组合对象，从而获得更大的灵活性。
- 适配器模式（Adapter Pattern）
- 描述：将一个类的接口转换成客户端所期待的另一种接口，从而使得原本由于接口不兼容而不能一起工作的类能够一起工作。
- 应用场景：当需要使用现有的类，但接口不符合要求时，或者当需要重用一些已存在的子类，但子类无法直接继承时。
- 桥接模式（Bridge Pattern）
- 描述：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
- 应用场景：当抽象和实现之间有明显的界限，且抽象和实现都需要独立变化时。
- 组合模式（Composite Pattern）
- 描述：将对象组合成树形结构以表示“部分-整体”的层次结构，使得客户对单个对象和复合对象的使用具有一致性。
- 应用场景：当需要表示对象的部分-整体的层次结构时，或者当需要让客户端忽略复合对象和单个对象的区别时。
- 装饰器模式（Decorator Pattern）
- 描述：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰器模式相比生成子类更为灵活。
- 应用场景：当需要动态地给一个对象添加功能，并且这些功能可以撤销时。
- 外观模式（Facade Pattern）
- 描述：为子系统中的一组接口提供一个统一的接口，降低系统的复杂性。
- 应用场景：当系统需要向客户端提供一个简单、一致的接口，以隐藏系统的复杂性时。
行为型模式
行为型模式 关注对象之间的通信和职责分配，它描述对象之间的交互模式以及分配职责。
- 观察者模式（Observer Pattern）
- 描述：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。当主题对象状态发生变化时，它的所有依赖者（观察者）都会收到通知并自动更新。
- 应用场景：当对象之间需要保持一种一对多的依赖关系时，如GUI组件、订阅-发布系统等。
- 策略模式（Strategy Pattern）
- 描述：定义了一系列的算法，并将每一个算法封装起来，使它们可以互相替换。策略模式使得算法可以独立于使用它的客户端变化。
- 应用场景：当需要在多种算法间进行选择和使用时，如排序算法、支付方式等。
- 模板方法模式（Template Method Pattern）
- 描述：定义了一个操作中的算法的框架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可
后续会持续更新分享相关内容，记得关注哦！
