xiaoyu❅的博客

职责链模式（Chain of Responsibility Pattern）, 又叫 责任链模式，为请求创建了一个接收者对象的链(简单示意图)。这种模式对请求的发送者和接收者进行解耦。职责链模式通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。这种类型的设计模式属于行为型模式总之，职责链模式提供了一种有效的处理请求的方式，使得系统更加灵活、可扩展且易于维护。

策略模式（Strategy Pattern）中，定义算法族（策略组），分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户这算法体现了几个设计原则，第一、把变化的代码从不变的代码中分离出来；第二、针对接口编程而不是具体类（定义了策略接口）；第三、多用组合/聚合，少用继承（客户通过组合方式使用策略）策略模式是一种行为设计模式，使你能在运行时改变对象的行为。

状态模式（State Pattern）是一种行为设计模式。它允许对象在内部状态改变时改变其行为，使得对象在不同的状态下表现出不同的行为。状态和行为是一一对应的，状态之间可以相互转换。当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了其类综上所述，状态模式通过将每个状态封装成独立的类，有效管理和简化了对象的状态转换和行为变化。尽管会增加类的数目和维护复杂度，但在处理复杂状态逻辑时提供了一种灵活且可扩展的设计方案。

解释器模式（Interpreter Pattern）是一种行为设计模式，用于定义一种语言的语法表示，并实现一个解释器来处理该语言中的句子。解释器模式：是指给定一个语言表达式，定义它的文法的一种表示，并定义一个解释器， 使用该解释器来解释语言中的句子表达式)在编译原理中，一个算术表达式通过词法分析器形成词法单元，而后这些词法单元再通过语法分析器构建语法分析树，最终形成一颗抽象的语法分析树。这里的词法分析器和语法分析器都可以看做是解释器。

备忘录模式（Memento Pattern）在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态可以这里理解备忘录模式：现实生活中的备忘录是用来记录某些要去做的事情，或者是记录已经达成的共同意见的事情，以防忘记了。而在软件层面，备忘录模式有着相同的含义，备忘录对象主要用来记录一个对象的某种状态，或者某些数据，当要做回退时，可以从备忘录对象里获取原来的数据进行恢复操作备忘录模式属于行为型模式。

中介者模式（Mediator Pattern），用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互中介者模式属于行为型模式，使代码易于维护综上所述，中介者模式通过引入中介者对象来封装和简化多个对象之间的交互，有效降低了系统的耦合度和复杂性。虽然其在某些情况下可能导致中介者类过于庞大和复杂，但总体而言，它提供了一种灵活、可扩展的设计方案，适用于处理复杂且动态变化的对象交互关系。

观察者模式是解决对象间一对多依赖关系的强大工具，通过状态改变的通知机制，它使得系统更加灵活和动态。然而，设计时也要注意其潜在的性能问题和循环依赖的问题。正确应用观察者模式，可以使你的系统更加模块化和易于扩展。

迭代器模式（Iterator Pattern）是常用的设计模式，属于行为型模式如果我们的集合元素是用不同的方式实现的，有数组，还有 java 的集合类，或者还有其他方式，当客户端要遍历这些集合元素的时候就要使用多种遍历方式，而且还会暴露元素的内部结构，可以考虑使用迭代器模式解决。迭代器模式，提供一种遍历集合元素的统一接口，用一致的方法遍历集合元素，不需要知道集合对象的底层表示，即：不暴露其内部的结构。迭代器模式是一种强大的设计模式，它使得遍历各种复杂的数据结构变得简单和统一。

访问者模式（Visitor Pattern），封装一些作用于某种数据结构的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。主要将数据结构与数据操作分离，解决 数据结构和操作耦合性问题在被访问的类里面加一个对外提供接待访问者的接口访问者模式主要应用场景是：需要对一个对象结构中的对象进行很多不同操作(这些操作彼此没有关联)，同时需要避免让这些操作"污染"这些对象的类，可以选用访问者模式解决。访问者模式是一种行为型设计模式。

命令模式（Command Pattern）：在软件设计中，我们经常需要向某些对象发送请求但是并不知道请求的接收者是谁，也不知道被请求的操作是哪个，我们只需在程序运行时指定具体的请求接收者即可，此时，可以使用命令模式来进行设计命名模式使得请求发送者与请求接收者消除彼此之间的耦合，让对象之间的调用关系更加灵活，实现解耦。在命名模式中，会将一个请求封装为一个对象，以便使用不同参数来表示不同的请求(即命名)，同时命令模式也支持可撤销的操作通俗易懂的理解：将军发布命令，士兵去执行。

模板方法模式（Template Method Pattern），又叫模板模式(Template Pattern)，在一个抽象类公开定义了执行它的方法的模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。简单说，模方法模式 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构，就可以重定义该算法的某些特定步骤这种类型的设计模式属于行为型模式。

静态代理在使用时,需要定义接口或者父类,被代理对象(即目标对象)与代理对象一起实现相同的接口或者是继承相同父类。代理对象,不需要实现接口，但是目标对象要实现接口，否则不能用动态代理代理对象的生成，是利用 JDK 的 API，动态的在内存中构建代理对象JDK 代理、接口代理静态代理和JDK 代理模式都要求目标对象是实现一个接口,但是有时候目标对象只是一个单独的对象,并没有实现任何的接口,这个时候可使用目标对象子类来实现代理，这就是 Cglib 代理Cglib 代理也叫作子类代理,

享元模式（Flyweight Pattern） 也叫蝇量模式: 运用共享技术有效地支持大量细粒度的对象常用于系统底层开发，解决系统的性能问题。像数据库连接池，里面都是创建好的连接对象，在这些连接对象中有我们需要的则直接拿来用，避免重新创建，如果没有我们需要的，则创建一个享元模式能够解决重复对象的内存浪费的问题，当系统中有大量相似对象，需要缓冲池时。不需总是创建新对象，可以从缓冲池里拿。这样可以降低系统内存，同时提高效率享元模式经典的应用场景就是池技术了，String 常量池、数据库连接池、缓冲池。

外观模式（Facade），也叫“过程模式：外观模式为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。外观模式通过定义一个一致的接口，用以屏蔽内部子系统的细节，使得调用端只需跟这个接口发生调用，而无需关心这个子系统的内部细节。综上所述，外观模式提供了一种高效的管理树形结构的方式，适用于各种具有层次结构的场景。虽然其设计和实现相对复杂，但其带来的好处是显著的。在选择使用组合模式时，还是需要根据具体需求来决定其适用性。

组合模式（Composite Pattern），又叫部分整体模式，它创建了对象组的树形结构，将对象组合成树状结构以表示“整体部分”的层次关系。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式。组合模式使得用户对单个对象和组合对象的访问具有一致性，即：组合能让客户以一致的方式处理个别对象以及组合对象综上所述，组合模式提供了一种高效的管理树形结构的方式，适用于各种具有层次结构的场景。虽然其设计和实现相对复杂，但其带来的好处是显著的。

桥接模式(Bridge 模式)是指：将实现与抽象放在两个不同的类层次中，使两个层次可以独立改变。是一种结构型设计模式Bridge 模式基于类的最小设计原则，通过使用封装、聚合及继承等行为让不同的类承担不同的职责。它的主要特点是把抽象(Abstraction)与行为实现(Implementation)分离开来，从而可以保持各部分的独立性以及应对他们的功能扩展综上所述，桥接模式的优点主要体现在提高了系统的灵活性和可维护性，同时降低了模块间的耦合度。这些优点使得桥接模式成为处理多维度变化问题的有效工具。

动态的将新功能附加到对象上。在对象功能扩展方面，它比继承更有弹性，装饰者模式也体现了开闭原则(ocp这里提到的动态的将新功能附加到对象和 ocp 原则综上所述，装饰者模式是一种结构型设计模式，它允许动态地向一个现有的对象添加新的功能，同时又不改变其结构。这种模式提供了一种灵活且低耦合的方法来扩展对象的功能，但它也可能带来一定的复杂性，因此在使用时应权衡利弊，合理设计。

一些书籍称为：适配器模式(Default Adapter Pattern)或缺省适配器模式。核心思路：当不需要全部实现接口提供的方法时，可先设计一个抽象类实现接口，并为该接口中每个方法提供一个默认实现（空方法），那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求适用于一个接口不想使用其所有的方法的情况。适配器模式通过提供一个中间层，解决了接口不兼容的问题，使得原本不能协同工作的类可以一起工作。它是实现“开闭原则”和“里氏替换原则”的一种方式，通过封装和抽象来达到接口适配的目的。

建造者模式（BuilderPattern） 又叫生成器模式，是一种对象构建模式。它可以将复杂对象的建造过程抽象出来（抽象类别），使这个抽象过程的不同实现方法可以构造出不同表现（属性）的对象。建造者模式 是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们， 用户不需要知道内部的具体构建细节。建造者模式在处理复杂对象的创建时提供了清晰的结构和流程，有利于代码的维护和扩展。

用原型实例指定创建对象的种类，并且通过拷贝这些原型，创建新的对象原型模式是一种创建型设计模式，允许一个对象再创建另外一个可定制的对象，无需知道如何创建的细节工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建，即 对象.clone()形象的理解：孙大圣拔出猴毛， 变出其它孙大圣Prototype : 原型类，声明一个克隆自己的接口ConcretePrototype: 具体的原型类, 实现一个克隆自己的操作。

简单工厂模式是属于创建型模式，是工厂模式的一种。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式简单工厂模式：定义了一个创建对象的类，由这个类来封装实例化对象的行为(代码)在软件开发中，当我们会用到大量的创建某种、某类或者某批对象时，就会使用到工厂模式.工厂方法模式通过定义一个创建对象的接口，将实际创建工作推迟到子类中去完成。这样，客户端代码在需要对象时，只需要调用接口，由子类给出具体的实现。

合成复用原则不仅是一种面向对象设计的具体实践，也是提升系统可维护性和扩展性的有力工具。在实际应用中合理运用这一原则，能够有效避免过度继承带来的弊端，提高代码质量。

单例模式是一个强大且常用的设计模式，适用于那些需要严格控制资源访问和系统开销的场合。合理地使用单例模式不仅能保证数据一致性和节省系统资源，还能提高应用程序的性能和效率。然而，开发者在使用过程中也需警惕其潜在的缺陷，以确保在适当的场景下发挥其最大的效用。

迪米特法则的核心是降低类之间的耦合但是注意：由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间(对象间)耦合关系 ,并不是要求完全没有依赖关系

里氏替换原则（Liskov Substitution Principle，简称LSP）里氏替换原则由麻省理工学院的Barbara Liskov在1987年首次提出。其核心思想是子类对象必须能够替换其基类对象，而程序行为不发生变化。也就是说，在一个软件系统中，子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。

二者都应该依赖其抽象抽象不应该依赖细节，细节应该依赖抽象依赖倒转(倒置)的中心思想是依赖倒转原则是基于这样的设计理念：相对于细节的多变性，的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在 java 中，抽象指的是接口或抽象类，细节就是具体的实现类，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

即类 A 通过接口 Interface 依赖类 B，类 C 通过接口 Interface 依赖类 D，如果接口 Interface 对于类 A 和类 C来说不是最小接口，那么类 B 和类 D 必须去实现他们不需要的方法。

UML——Unified modeling language UML (统一建模语言)，是一种用于软件系统分析和设计的语言工具，它用于帮助软件开发人员进行思考和记录思路的结果UML 本身是一套符号的规定，就像数学符号和化学符号一样，这些符号用于描述软件模型中的各个元素和他们之间的关系，比如等。对于这两种关系比较简单，它们体现的是一种类与类、或者类与接口之间的纵向关系。其他的四种关系则体现的是类与类、或者类与接口之间的引用/横向关系。这四种关系所表现的强弱程度来看，从强到弱依次为：>聚合>关联>依赖。

单一职责原则是面向对象设计中的一个核心原则，它鼓励开发者将复杂的系统分解为多个小而专的模块，每个模块负责一个职责。这样做不仅提高了代码的可维护性、可读性和可扩展性，还降低了代码的复杂性和出错的概率。

设计模式的关键在于理解每个模式的核心原理及其解决的特定问题，然后根据实际需求来选择最适合的模式。正确应用设计模式能够显著提高软件的可维护性、扩展性和复用性。