1。开闭原理
开放用于扩展，关闭用于修改。
2。里氏替换原理
只有当派生类能够替代基类且不影响软件单元的功能时，基类才能真正得到复用，并且派生类还可以在基类的基础上添加新的行为。
3。依赖倒置原理
这是开闭原则的基础，编程接口依赖于抽象而不是具体。
4。接口隔离原则
使用多个隔离接口来减少耦合。
5。德米特原理（德米特原理）
一个实体应尽可能少地与其他实体交互，使系统功能模块相对独立。
6。复合再利用原则
原则是尽可能使用组合/聚合，而不是继承。继承实际上破坏了类的封装性，超类的方法可能会被子类修改。
1。单例模式
单例模式，它的定义是保证一个类只有一个实例并提供一个全局访问点。
单例模式具有三个典型特征： 1、只有一个实例。 2. 自实例化。 3. 提供全球接入点。
因此，当系统中只需要一个实例对象或者系统中只允许有一个公共访问点，且无法通过除该公共访问点之外的其他访问点访问该实例时，可以使用单例模式。
单例模式的主要优点是节省系统资源，提高系统效率。同时也可以严格控制客户的访问权限。也许是因为系统中只有一个实例，导致单例类的职责过重，违反了“单一职责原则”。同时，没有抽象类，因此难以扩展。它的UML结构图非常简单，只有一个类，如下图：
2。工厂方法模式
作为抽象工厂模式的孪生兄弟，工厂方法模式定义了一个用于创建对象的接口，但是由子类来决定实例化哪个类，这意味着工厂方法模式将实例化推迟到了子类。
工厂方法模式非常符合“开闭原则”。当我们需要添加新的产品时，只需要添加特定的产品类别和对应的特定工厂，无需修改原有系统。同时，在工厂方法模式中，用户只需要知道生产产品的具体工厂，不需要知道产品的创建过程，甚至不需要知道具体的产品类名。虽然它很好地遵守了“开闭原则”，但由于每次增加一个新产品，都需要增加两个类，这必然会导致系统复杂度的增加。其UML结构图：
3。抽象工厂模式
所谓的抽象工厂模式提供了一个接口，用于创建一系列相关或依赖的对象，而无需显式指定特定的类。它允许客户使用抽象接口来创建一组相关的产品，而不必担心实际生产的具体产品。这样，客户就可以与特定产品脱钩。它的优点是隔离了具体类的生成，这样客户端不需要知道创建了什么，但缺点是添加新的行为会比较麻烦，因为添加新的产品对象时，比较需要更改界面及其下面的所有子类别。其UML结构图如下：
4.建造者模式
对于构建器模式来说，它主要是将一个复杂对象的构建和表示分离，使得同一个构建过程可以创建不同的表示。适用于这些产品对象的内部结构更加复杂。
建造者模式将复杂产品的构建过程封装并分解为不同的方法，使得创建过程非常清晰，让我们能够更准确地控制复杂产品对象的创建过程。同时，它隔离了复杂产品对象的创建和创建。用于启用相同的创建过程来创建不同的产品。但如果某个产品的内部结构过于复杂，整个系统就会变得非常庞大，不利于控制。同时，如果几个产品之间差异较大，则builder模式就不适用了。毕竟，有太多共同点的两种产品并不多，所以它的使用范围是有限的。其UML结构图：
5。原型模式
在我们的应用中，可能会有一些结构比较复杂的对象，但是我们需要经常使用它们。如果这个时候我们不断地创建新的对象，势必会消耗大量的系统内存。这时候我们就需要用到原型了。克隆这个结构复杂、使用频繁的对象的模式。所以原型模式使用原型实例来指定要创建的对象的类型，并通过复制这些原型来创建新的对象。
主要用于创建新对象的成本太高的情况。它的主要优点是简化了新对象的创建过程，提高了效率。同时，原型模式提供了简化的创建结构。 UML结构图：
模式结构
原型模式包含以下角色：
Prototype：抽象原型类
ConcretePrototype：具体原型类
Client：客户端类
6.适配器模式
在我们的应用程序中，我们可能需要在具有不同接口的两个类之间进行通信。在不修改这两个的情况下，我们可能需要一些中间件来完成连接过程。这个中间件就是适配器。所谓适配器模式，就是将一个类的接口转换成客户期望的另一个接口。它让两个原本不兼容的接口能够无缝连接。
作为中间件适配器，适配器将目标类和适配器解耦，增加了类的透明度和可重用性。
适配器模式包含以下角色：
Target：目标抽象类
Adapter：适配器类
Adaptee：适配器类
Client：客户端类
7。桥接模式
如果一个系统可以从多个角度进行分类，并且每个分类都可能发生变化，那么我们需要做的就是将这多个角度分开，使它们能够独立变化，减少它们之间的冲突。它们之间的耦合，这个分离过程采用的是桥接模式。所谓桥接模式，就是将抽象部分和实现部分隔离开来，让它们可以独立改变。
桥接模式将继承关系转换为关联关系，封装变化，完成解耦，减少系统中的类数量，也减少代码量。
桥接模式包括以下角色：
Abstraction：抽象类
RefinedAbstraction：扩展抽象类
Implementor：实现类接口
ConcreteImplementor：具体实现
8。组合模式
组合模式将多个对象组合起来形成树形结构，表示“整体-部分”的结构层次。它定义了如何递归地组合容器对象和叶子对象，以便客户在使用过程中无需区分，可以一致地处理它们。使用组合模式时需要注意的一件事也是组合模式最关键的一点：叶对象和组合对象实现相同的接口。这就是组合模式一致地处理叶节点和对象节点的原因。
组合模式虽然可以清晰地定义层次化的复杂对象，并且更容易添加新的组件，但这导致系统设计变得更加抽象。如果系统的业务规则比较复杂，使用组合模式有一定的挑战。
模式结构
组合模式包含以下角色：
Component：抽象组件
Leaf：叶子组件
Composite：容器组件
Client：客户端类
9。装饰模式
我们可以通过继承和组合为对象添加行为。继承虽然可以很好的拥有父类的行为，但是它有几个缺陷： 1、如果对象之间的关系复杂，系统就会变得复杂，不利于维护。 2、容易产生“爆炸状”现象。第三，它是静态的。这里我们可以使用装饰器模式来解决这个问题。
装饰器模式，动态地将职责附加到对象。为了扩展功能，装饰器提供了比继承更灵活的替代方案。虽然装饰器模式可以动态地将职责附加到对象上，但它会生成许多小对象，增加系统的复杂性。
10.外观模式
我们都知道类之间的耦合度越低，复用性就越好。如果两个类不需要相互通信，那么就不要让两个类彼此有直接的关系。如果需要调用里面的方法可以通过第三方转发。外观模型很好的解释了这段话。外观模式提供了一个统一的接口来访问子系统中的一组接口。它最大限度地减少了应用程序中子系统之间的相互依赖性，并为子系统提供了一个简单的单一屏障，客户端通过该屏障与子系统进行通信。通过使用外观模式，客户端对子系统的引用变得简单，并且实现了客户端与子系统之间的松耦合。但它违反了“开闭原则”，因为添加新的子系统可能需要修改外观类或客户端的源代码。
外观模式包含以下角色：
Facade：外观角色
SubSystem：子系统角色
11。亨元模式
系统中的对象会占用过多的内存，尤其是那些有大量重复的对象，对系统资源是巨大的浪费。 Flyweight模式通过使用共享技术重用相同或相似的对象，提供了对象重用的解决方案。 Flyweight模式是一种运行时共享技术，有效支持大量细粒度对象的复用。系统使用的对象数量较少，而且这些对象比较相似，状态变化较小，并且对象可以多次重用。这里需要注意一件事：享元模式要求可以共享的对象必须是细粒度的对象。享元模式通过共享技术大大减少了系统中的对象数量。同时，享元模式使用内部和外部状态。同时，外部状态相对独立，不会影响内部状态，因此享元模式可以使享元对象在不同环境之间共享。同时又分为内部状态和外部状态。享元模式会让系统变得更加复杂，同时也会导致读取外部状态的时间过长。
12.代理模式
代理模式是为一个对象提供一个代理，代理对象控制对原始对象的引用。它阻止客户端直接与真实的目标对象进行通信。代理对象是目标对象的代表，其他需要与目标对象打交道的操作都是与这个代理对象协商的。
代理对象可以在客户端和目标对象之间起到中介作用，起到了重要的作用，保护了目标对象，同时也在一定程度上降低了系统的耦合度。
代理模式包括以下角色：
主体：抽象主体角色
代理：代理主体角色
真实主体：真实主体角色
13。访客模式
访客模式俗称23种主要设计模式中最难的一种。除了结构复杂之外，也很难理解。在我们的软件开发中，我们可能会对同一个对象进行不同的处理。如果我们都单独处理，就会发生灾难性的错误。对于这个问题，访客模式提供了更好的解决方案。访问者模式表示作用于对象结构中每个元素的操作。它允许我们定义作用于这些元素的新操作，而无需更改每个元素的类。
访问者模式的目的是封装一些应用于某些数据结构元素的操作。一旦需要修改这些操作，接受该操作的数据结构可以保持不变。提供针对不同类型元素的多种访问操作方式，无需修改原有系统即可添加新的操作方式。同时我们还需要明确的是，访问者模式适合那些相对稳定的数据结构，因为它将数据操作与数据结构分离。如果某个系统的数据结构比较稳定，但是操作算法容易改变的话，那么访问者模式就更适合，因为访问者模式更容易增加算法操作。
14。模板模式
有时，我们做某些事情所采取的步骤是相似的，只有很小的差异。软件开发领域也是如此。如果这些步骤我们都一一去做，那就费时、费力、吃力不讨好。 。所以我们可以将这些步骤分解封装起来，然后用继承的方式来继承。当然，你可以自己重写并实现不同的！这就是模板方法模式提供的解决方案。
所谓模板方法模式，就是在方法中定义算法的骨架，并将一些步骤推迟到子类中。模板方法允许子类在不改变算法结构的情况下重新定义算法中的某些步骤。
模板方法模式基于继承代码重用技术。在模板方法模式中，我们可以将相同部分的代码放在父类中，而将不同的代码放在不同的子类中。也就是说，我们需要声明一个抽象父类，以具体方法和具体构造函数的形式实现部分逻辑，然后再声明一些抽象方法让子类实现剩余的逻辑。不同的子类可以用不同的方式来做到这一点。实现这些逻辑。所以模板方法的模板其实就是一个普通的方法，只不过这个方法封装了算法实现的步骤。
模板方法模式包含以下角色：
AbstractClass：抽象类
ConcreteClass：具体子类
15。策略模式
我们知道，实现一件事可能有很多种方法，但总有一种是最有效的方法。软件开发领域也是如此。我们实现一个功能的方式也有很多种，但是我们需要一种简单高效的方式来实现，让系统变得非常灵活，这就是策略模式。
所以策略模式定义了一系列算法，并分别封装它们，以便它们可以相互转换。在这个模型中，算法的变化与使用该算法的客户无关。
在策略模型中，它将这些解决问题的方法定义为一个算法组。每种方法都对应一种特定的算法。我在这里将算法称为策略。策略模式虽然定义了算法，但是并没有提供算法的选择，即哪种算法最适合什么问题。这不是策略模式关心的，所以策略的选择还是需要客户端来完成。客户必须清楚地知道每种算法之间的区别以及何时何地使用什么策略最合适，这增加了客户的负担。
同时，策略模型也完美符合“开闭原则”。用户可以在不修改原有系统的情况下选择算法或行为，也可以灵活添加新的算法或行为。但一种策略对应一类，会导致系统生成很多策略类。
策略模式包含以下角色：
Context：环境类
策略：抽象策略类
具体策略：具体策略类
16。状态模式
在许多情况下，对象的行为取决于其一个或多个不断变化的属性。这些可变的属性称为状态，也就是说行为取决于状态，即当对象由于外部交互而发生变化时，其状态就会改变，其行为也会相应改变。在这种情况下，我们就无法用行为来控制状态的变化。相反，我们应该从国家的角度来思考行为，即根据国家的情况应该做什么样的行为。这就是状态模式。
因此，状态模式允许对象在其内部状态发生变化时改变其行为。该对象将显示为好像已修改其类。
在状态模式下，我们可以减少大块的 if...else 语句，从而允许状态转换逻辑和状态对象的集成。然而，减少if...else语句的代价是会得到大量的类，所以状态模式势必会增加系统中类或对象的数量。
同时状态模式将与某个状态相关的所有行为放到一个类中，并且可以方便地添加新状态，并且只需要改变对象状态即可改变对象的行为。然而，这将使系统的结构和实现变得更加复杂。如果使用不当，程序的结构和代码将会混乱，不利于维护。
状态模式包括以下角色：
Context：环境类
State：抽象状态类
ConcreteState：具体状态类
17。观察者模式
什么是观察者模式？观察者模式定义了对象之间的一对多依赖关系，以便当对象更改状态时，其所有依赖关系都会得到通知并自动更新。
这里，发生变化的对象称为观察目标，被通知的对象称为观察者。一个观察目标可以对应多个观察者，并且这些观察者彼此之间没有关联，因此可以根据需要添加和删除观察者，使得系统更容易扩展。因此，观察者提供了一种对象设计，允许主体和观察者以松散耦合的方式组合在一起。
含 观察者模式包含以下字符：
Subject：目标
Concretesubject：特定目标
ObServer：观察者
ConcreteobServer：特定观察者
18.备忘录模式
每个人都想要后悔药，但事实是残酷的。根本没有后悔药可买，不仅如此，软件世界里还有后悔药！备忘录模式是一种后悔药。它为我们的软件提供了后悔药机制，通过该机制可以将系统恢复到特定的历史状态。
所谓备忘录模式，就是在不破坏封装性的情况下，捕获对象的内部状态，并将此状态保存在对象外部，以便以后可以将对象恢复到原来保存的状态。它封装了信息，使客户无需关心状态保存的细节。保存会消耗资源，所以备忘录模式的缺点就是消耗资源。如果一个类的成员变量过多，必然会占用比较大的资源，每次保存都会消耗一定的内存。
备忘录模式包括以下角色：
Originator：发起者
Memento：备忘录
Caretaker：负责人
19。中介模型
大家都有过租房子的经历吧！中间结构在这个过程中起着非常重要的作用。它在这里充当中间人，在我们和房主之间相互传递信息。软件外部世界也需要这样的中间人。在我们的系统中，有时对象之间存在强烈而复杂的关系。如果它们之间有直接的联系，肯定会导致整个系统变得非常复杂和可扩展。很坏！我们之前就知道，如果两个类不需要相互通信，我们就不应该让它们有直接的关系。如果确实需要沟通，我们可以通过第三方转发他们的请求。同样，这里我们使用中介来解决这个问题。
所谓中介者模式，使用中介者对象来封装一系列的对象交互。中介器消除了对象显式相互引用的需要，从而放松了它们的耦合并允许它们独立地改变它们之间的交互。在中介者模式中，中介者对象用于封装对象之间的关系。每个对象都可以通过中介对象相互通信，而无需知道具体信息。它减少了对象之间的相互关系，提供了系统的可重用性，简化了系统结构。
在中介者模式中，每个对象不需要互相认识，它们只需要知道中介者对象，但是中介者对象必须知道所有的对象以及它们之间的关系，正是因为这样，结果，中介对象的结构过于复杂，承担的职责过多。同时，它也是整个系统的核心。一旦出现问题，就会导致整个系统出现问题。因此，如果系统设计过程中存在复杂的“多对多”关系组，不要急于使用中介模式，而是要仔细考虑一下你设计的系统是否存在问题。
Mediator：抽象中介者
ConcreteMediator：具体中介者
Colleague：抽象同事类
ConcreteColleague：具体同事类
20。迭代器模式
我们在编程过程中经常使用迭代。它可以漫游聚合中的每个元素，并且还可以提供多种不同的遍历方法。这就是迭代器模式的设计动机。在我们实际的开发过程中，我们可能需要根据不同的需求，用不同的方式来遍历整个对象，但是我们不希望聚合对象的抽象接口充满各种遍历操作，所以我们希望有一个东西可以以多种不同的方式迭代聚合对象，这就是迭代器模式发挥作用的时候。
什么是迭代器模式？所谓迭代器模式就是提供一种方法来顺序访问聚合对象中的每个元素，而不是暴露其内部表示。迭代器模式将迭代元素的职责分配给迭代器而不是聚合对象。我们甚至可以在不知道聚合对象的内部结构的情况下迭代聚合对象。
迭代器模式使聚合对象的结构更加简单。它不需要关注其元素的遍历，而只需要关注其应该关注的内容，这更符合单一责任原则。
Iterator 模式包括以下角色：
Iterator：抽象迭代器
ConcreteIterator：具体迭代器
Aggregate：抽象聚合类
ConcreteAggregate：具体聚合类
21。口译模式
所谓解释器模式，就是定义语言的语法，构建一个解释器来解释该语言中的句子。解释器模式描述了如何构造一个简单的语言解释器，主要用于使用面向对象语言开发的编译器。它描述了如何定义简单语言的语法、如何用该语言表示句子以及如何解释这些句子。
解释器模式包含以下角色：
AbstractExpression：抽象表达式
TerminalExpression：终结符
NonterminalExpression：非终结符
Context：环境类 Client：客户类
22。命令模式
有时候我们想向某个对象发送请求，但我们不知道请求的具体接收者是谁，具体的处理过程是什么。我们只知道程序运行时指定了具体的请求接收者。是的，我们把这种将请求封装成对象的方法称为命令模式。因此命令模式将请求封装到对象中，以便可以使用不同的请求、队列或日志来参数化其他对象。同时，命令模式支持可撤消的操作。
命令模式可以将请求的发送者和接收者完全解耦。发送者和接收者之间没有直接联系。发送者只需要知道如何发送请求命令即可，其余的都没关系，甚至命令是否成功，都不需要关心。同时我们可以很方便的添加新的命令，但是或许因为方便和对请求的封装，系统中会出现太多的具体命令类。
23。责任链模型
责任链模式描述了请求如何沿着对象链传递。它形成一条对象链，发送者将请求发送给链中的第一个接收者，并沿着链传递，直到有对象可以处理它或者直到最后没有对象可以处理并停留在该链上。链的末端。
避免请求发送者和接收者耦合，让多个对象可以接收请求，将这些对象连接成一条链，并沿着这条链传递请求，直到有一个对象处理它，这就是责任链模型。在责任链模型中，每个对象都有处理请求的可能性，从而实现请求的发送者和接收者之间的解耦。同时，责任链模型简化了对象的结构。它允许每个对象仅引用其后继者，而不必了解整个链。这不仅提高了系统的灵活性，也使得添加新的请求处理类变得更加容易。更方便。但在责任链中我们无法保证所有请求都能被处理，也不利于观察运行时特性。
责任链模式包括以下角色：
Handler：抽象处理程序
ConcreteHandler：具体处理程序
Client：客户端类
引用自：
https://www.sychzs.cn/pony1223/p/7608955.html
https://www.sychzs.cn/zhaojinyan/p/9401010.html
-->
