weixin_45417821的博客

职责链模式（Chain of Responsibility Pattern）, 又叫 责任链模式，为请求创建了一个接收者对象的链(简单示意图)。这种模式对请求的发送者和接收者进行解耦。职责链模式通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。这种类型的设计模式属于行为型模式。

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

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

中介者模式（Mediator Pattern），用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互中介者模式属于行为型模式，使代码易于维护比如 MVC 模式，C（Controller 控制器）是 M（Model 模型）和 V（View 视图）的中介者，在前后端交互时起到了中间人的作用。

状态模式（State Pattern）：它主要用来解决对象在多种状态转换时，需要对外输出不同的行为的问题。状态和行为是一一对应的，状态之间可以相互转换当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了其类。

在编译原理中，一个算术表达式通过词法分析器形成词法单元，而后这些词法单元再通过语法分析器构建语法分析树，最终形成一颗抽象的语法分析树。这里的词法分析器和语法分析器都可以看做是解释器解释器模式（Interpreter Pattern）：是指给定一个语言(表达式)，定义它的文法的一种表示，并定义一个解释器，使用该解释器来解释语言中的句子(表达式)应用场景①应用可以将一个需要解释执行的语言中的句子表示为一个抽象语法树②一些重复出现的问题可以用一种简单的语言来表达③一个简单语法需要解释的场景。

观察者模式：对象之间多对一依赖的一种设计方案，被依赖的对象为 Subject，依赖的对象为 Observer，Subject通知 Observer 变化,比如这里的奶站是 Subject，是 1 的一方。在 WeatherData 中，当增加一个第三方，都需要创建一个对应的第三方的公告板对象，并加入到 dataChange, 不利于维护，也不是动态加入。2）当数据有更新时，气象站通过调用dataChange() 去更新数据，当第三方再次获取时，就能得到最新数据，当然也可以推送。Observer：接收输入。

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

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

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

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

代理模式：为一个对象提供一个替身，以控制对这个对象的访问。即通过代理对象访问目标对象。这样做的好处是：可以在目标对象实现的基础上，增强额外的功能操作，即扩展目标对象的功能。被代理的对象可以是远程对象、创建开销大的对象或需要安全控制的对象代理模式有不同的形式, 主要有三种 静态代理、动态代理 (JDK 代理、接口代理)和 Cglib 代理 (可以在内存动态的创建对象，而不需要实现接口， 他是属于动态代理的范畴)代理模式示意图。

外观模式（Facade），也叫“过程模式：外观模式为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用外观模式通过定义一个一致的接口，用以屏蔽内部子系统的细节，使得调用端只需跟这个接口发生调用，而无需关心这个子系统的内部细节。

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

组合模式（Composite Pattern），又叫部分整体模式，它创建了对象组的树形结构，将对象组合成树状结构以表示“整体-部分”的层次关系。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式。组合模式使得用户对单个对象和组合对象的访问具有一致性，即：组合能让客户以一致的方式处理个别对象以及组合对象。

装饰者模式：动态的将新功能附加到对象上。在对象功能扩展方面，它比继承更有弹性，装饰者模式也体现了开闭原则(ocp)这里提到的动态的将新功能附加到对象和 ocp 原则，在后面的应用实例上会以代码的形式体现，请同学们注意体会。

基本介绍桥接模式(Bridge 模式)是指：将实现与抽象放在两个不同的类层次中，使两个层次可以独立改变。是一种结构型设计模式Bridge 模式基于类的最小设计原则，通过使用封装、聚合及继承等行为让不同的类承担不同的职责。它的主要特点是把抽象(Abstraction)与行为实现(Implementation)分离开来，从而可以保持各部分的独立性以及应对他们的功能扩展。

适配器模式(Adapter Pattern)将某个类的接口转换成客户端期望的另一个接口表示，主的目的是兼容性，让原本因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper)适配器模式属于结构型模式类适配器模式、对象适配器模式、接口适配器模式基本介绍：Adapter 类，通过继承 src 类，实现 dst 类接口，完成 src->dst 的适配。基本思路和类的适配器模式相同，只是将 Adapter 类作修改，不是继承 src 类，而是持有 src 类的实例，以解决兼容性的问题。

建造者模式（Builder Pattern）是一种创建型设计模式，用于将一个复杂对象的构建过程与其表示分离，从而使得同样的构建过程可以创建不同的表示。这种模式的主要目标是将一个复杂对象的构建步骤进行解耦，使得构建过程更加灵活，并且可以通过不同的步骤组合来创建不同的对象。基本上，建造者模式将对象的构建过程分为多个步骤，每个步骤由一个具体的建造者类负责实现。然后，一个指挥者类负责协调这些建造者，按照特定的顺序和组合来执行建造步骤，最终生成所需的复杂对象。

原型模式（Prototype Pattern）是一种创建型设计模式，旨在通过复制现有对象来创建新对象，而无需显式地使用构造函数。这种模式允许我们创建一个原型对象，然后通过克隆这个原型来生成新的对象实例，从而避免了重复创建相似对象的开销。原型模式的主要思想是，通过复制现有对象的状态来创建新对象，而不是从头开始重新构建对象。这对于某些对象的创建过程较为复杂，或者需要保持一致的初始状态时，是一种很有用的模式。形象的理解：孙悟空拔出猴毛， 变出其它孙悟空。

工厂模式是一种创建型设计模式，它提供了一种创建对象的接口，但将对象的实例化过程推迟到子类或具体的实现类中。工厂模式的主要目的是将对象的创建与使用分离，从而降低代码的耦合性，增强代码的可维护性和可扩展性。简单工厂模式是属于创建型模式，是工厂模式的一种。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式简单工厂模式：定义了一个创建对象的类，由这个类来封装实例化对象的行为(代码)

所谓类的单例设计模式，就是采取一定的方法保证在整个的软件系统中，对某个类只能存在一个对象实例，并且该类只提供一个取得其对象实例的方法(静态方法)。比如 Hibernate 的 SessionFactory，它充当数据存储源的代理，并负责创建 Session 对象。SessionFactory 并不是轻量级的，一般情况下，一个项目通常只需要一个 SessionFactory 就够，这是就会使用到单例模式。

设计模式是什么？设计模式的一般定义为：设计模式（Design Pattern）是一套反复使用、多人知晓的，经过分类编目的，代码设计总结经验，使用设计模式是为了可重用代码，让代码更容易被他人理解并保证代码可靠性设计模式一般包含模式名称、问题、目的、解决方案、效果等组成要素，我们一般比较关注的是模式名称（Pattern Name），问题（Problem），解决方案（Solution）和效果（Consequences）设计模式的本质提高 软件的维护性，通用性和扩展性，并降低软件的复杂度。

1）UML——Unified modeling language UML (统一建模语言)，是一种用于软件系统分析和设计的语言工具，它用于帮助软件开发人员进行思考和记录思路的结果聚合关系（Aggregation）表示的是整体和部分的关系，整体与部分可以分开。聚合关系是关联关系的特例，所以他具有关联的导航性与多重性。如：一台电脑由键盘(keyboard)、显示器(monitor)，鼠标等组成；//鼠标可以和 computer 不能分离//显示器可以和 Computer 不能分离。

依赖：对类 B 进行修改会影响到类 A。关联：对象 A 知道对象 B。类 A 依赖于类 B。聚合：对象 A 知道对象 B 且由 B 构成。类 A 依赖于类 B。组合：对象 A 知道对象 B、由 B 构成而且管理着 B 的生命周期。类 A 依赖于类 B。实现：类 A 定义的方法由接口 B 声明。对象 A 可被视为对象B。类 A 依赖于类 B。继承： 类 A 继承类 B 的接口和实现， 但是可以对其进行扩展。对象 A 可被视为对象 B。类 A 依赖于类 B。

在上面的代码中，Animal 类是一个基类，它有一个私有的 name 属性和一个 makeSound 方法。在上面的代码中，学校类（School）使用聚合关系，将学生对象（Student）聚合到学校中。然后，我将学生对象添加到学校中，并调用学校对象的显示学生方法，以展示学校中的学生信息。这个示例展示了如何在学校类中使用聚合关系，将学生对象聚合到学校中，并通过main方法来演示学校的学生管理。这个示例展示了如何在汽车类中使用合成关系，将引擎对象组合到汽车中，并通过main方法来演示汽车的使用。

一个对象应该对其他对象保持最少的了解类与类关系越密切，耦合度越大迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息迪米特法则还有个更简单的定义：只与直接的朋友通信直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。

开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。

里氏替换原则(Liskov Substitution Principle)在 1988 年，由麻省理工学院的以为姓里的女士提出的。如果对每个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法。

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

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上先看一张图:类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，如果接口 Interface1 对于类 A 和类 C来说不是最小接口，那么类 B 和类 D 必须去实现他们不需要的方法。按隔离原则应当这样处理：将接口 Interface1 拆分为独立的几个接口(这里我们拆分成 3 个接口)，类 A 和类 C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

对类来说的，即一个类应该只负责一项职责。如类 A 负责两个不同职责：职责 1，职责 2。当职责 1 需求变更而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为 A1，A2。