设计模式

1      系统结构

 

 

抽象：同类抽象，变化抽象。

分离：过程分离（），角色分离，整体和部分分离，根据实际事实分离和衔接。

衔接：持有或聚合关系，继承

 

根据实际事实分离和衔接。

2      设计

结构型和行为型。

报表：使用者自己可以配置和建模，然后自动生成。

3     (创建型)_单例模式

在它的核心结构中只包含一个被称为单例的特殊类。通过单例模式可以保证系统中一个类只有一个实例。即一个类只有一个对象实例.

 

数学与逻辑学中，singleton定义为“有且仅有一个元素的集合”。

 

单例模式最初的定义出现于《设计模式》（艾迪生维斯理,1994）：“保证一个类仅有一个实例，并提供一个访问它的全局访问点。”

 

public class InneSingleton{

    // 私有默认构造子

    private InneSingleton() {

}

 

    // 类级的内部类，也就是静态的成员式内部类，该内部类的实例与外部类的实例没有绑定关系，而且只有被调用到时才会装载，从而实现了延迟加载。

    private static class SingletonHolder {

        // 静态初始化器，由JVM来保证线程安全

        private static InneSingleton  instance = new InneSingleton();

    }

 

    // 公有获取实例方法

    public static InneSingleton  getInstance() {

        return SingletonHolder.instance;

    }

 

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/77852523

Java中单例模式定义：“一个类有且仅有一个实例，并且自行实例化向整个系统提供。”

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/77852523

4     创建型：原型模式

原型模式是指用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节。工作原理：通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。

 

原型模式主要面对的问题是：某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是他们却拥有比较稳定一致的接口。

 

原型模式有两种拷贝情况：浅复制和深复制。

 

1）浅复制：将一个对象复制后，基本数据类型的变量都会重新创建，而引用类型，指向的还是原对象所指向的。

 

2）深复制：将一个对象复制后，不论是基本数据类型还有引用类型，都是重新创建的。

————————————————

版权声明：本文为CSDN博主「@黄小泽」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/zeping891103/article/details/53765536

5     (创建型)_工厂模式

按类型和特点集中起来，分情况创建对应的对象。

6     (创建型)_建造者模式

 建造者模式是设计模式的一种，将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

 

实用范围

1 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。

2 当构造过程必须允许被构造的对象有不同表示时。

 

角色

 在这样的设计模式中，有以下几个角色：

1 builder：为创建一个产品对象的各个部件指定抽象接口。

2 ConcreteBuilder：实现Builder的接口以构造和装配该产品的各个部件，定义并明确它所创建的表示，并 提供一个检索产品的接口。

3 Director：构造一个使用Builder接口的对象。

4 Product：表示被构造的复杂对象。ConcreteBuilder创建该产品的内部表示并定义它的装配过程，包含定义组成部件的类，包括将这些部件装配成最终产品的接口。

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78042555

7      结构型_桥接

处理有多个分支（分支可扩展），抽象一个（抽象类）桥（子类可以扩展），聚合（持有）分支的接口。

使用：子类桥直接调用持有的接口。

 

 

 

桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化。桥接的用意是：将抽象化与实现化解耦，使得二者可以独立变化，像我们常用的JDBC桥DriverManager一样，JDBC进行连接数据库的时候，在各个数据库之间进行切换，基本不需要动太多的代码，甚至丝毫不用动，原因就是JDBC提供统一接口，每个数据库提供各自的实现，用一个叫做数据库驱动的程序来桥接就行了。我们来看看关系图：

 

桥接模式实现了至少三条很重要的原则就是“单一职责原则”，“依赖倒置原则”，“开闭原则”。

优点与缺点

桥接模式的主要优点如下：

(1)分离抽象及其实现接口部分。桥接模式使用“对象间的关联关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自维度的变化，也就是说抽象和实现不再在同一个继承层次结构中，而是“子类化”它们，使它们各自都具有自己的子类，以便任何组合子类，从而获得多维度组合对象。

 

(2)在很多情况下，桥接模式可以取代多层继承方案，多层继承方案违背了“单一职责原则”，复用性较差，且类的个数非常多，桥接模式是比多层继承方案更好的解决方法，它极大减少了子类的个数。

 

(3)桥接模式提高了系统的可扩展性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统，符合“开闭原则”。

 

桥接模式的主要缺点如下：

(1)桥接模式的使用会增加系统的理解与设计难度，由于关联关系建立在抽象层，要求开发者一开始就针对抽象层进行设计与编程。

 

(2)桥接模式要求正确识别出系统中两个独立变化的维度，因此其使用范围具有一定的局限性，如何正确识别两个独立维度也需要一定的经验积累。

 

 

 ————————————————

版权声明：本文为CSDN博主「林花谢了春红」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/a1610770854/article/details/53469065

4.适用场景

在以下情况下可以考虑使用桥接模式：

 

(1)如果一个系统需要在抽象化和具体化之间增加更多的灵活性，避免在两个层次之间建立静态的继承关系，通过桥接模式可以使它们在抽象层建立一个关联关系。

 

(2)“抽象部分”和“实现部分（行为方法）”可以以继承的方式独立扩展而互不影响，在程序运行时可以动态将一个抽象化子类的对象和一个实现化子类的对象进行组合，即系统需要对抽象化角色和实现化角色进行动态耦合。

 

(3)一个类存在两个（或多个）独立变化的维度，且这两个（或多个）维度都需要独立进行扩展。

 

(4)对于那些不希望使用继承或因为多层继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。

8     结构型_装饰模式(Decorator)

 动态地给一个对象增加一些额外的职责(Responsibility)，就增加对象功能来说，装饰模式比生成子类实现更为灵活。其别名也可以称为包装器(Wrapper)，与适配器模式的别名相同，但它们适用于不同的场合。根据翻译的不同，装饰模式也有人称之为“油漆工模式”，它是一种对象结构型模式

 ————————————————

版权声明：本文为CSDN博主「林花谢了春红」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/a1610770854/article/details/53501089

 

 

class WaterCar extends SuperCar{

 

 

    public WaterCar(ICar car) {

        super(car);

    }

 

    public void swim(){

        System.out.println("水上游");

    }

 

    @Override

    public void move() {

        super.move();

        swim();

    }

 

}

 ————————————————

版权声明：本文为CSDN博主「张志飞」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/qq_28009065/article/details/77887006

3.优缺点

1).装饰模式的主要优点如下：

(1) 对于扩展一个对象的功能，装饰模式比继承更加灵活性，不会导致类的个数急剧增加。

 

(2) 可以通过一种动态的方式来扩展一个对象的功能，通过配置文件可以在运行时选择不同的具体装饰类，从而实现不同的行为。

 

(3) 可以对一个对象进行多次装饰，通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合，得到功能更为强大的对象。

 

(4) 具体构件类与具体装饰类可以独立变化，用户可以根据需要增加新的具体构件类和具体装饰类，原有类库代码无须改变，符合“开闭原则”。

 

 

2).装饰模式的主要缺点如下：

(1) 使用装饰模式进行系统设计时将产生很多小对象，这些对象的区别在于它们之间相互连接的方式有所不同，而不是它们的类或者属性值有所不同，大量小对象的产生势必会占用更多的系统资源，在一定程序上影响程序的性能。

 

(2) 装饰模式提供了一种比继承更加灵活机动的解决方案，但同时也意味着比继承更加易于出错，排错也很困难，对于多次装饰的对象，调试时寻找错误可能需要逐级排查，较为繁琐。

 

 

4.适用场景

在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。

需要动态地给一个对象增加功能，这些功能也可以动态地被撤销。

当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。不能采用继承的情况主要有两类：第一类是系统中存在大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长；第二类是因为类定义不能继承（如final类）.

5.与桥接模式的区别

个人感觉装饰模式只是为了给基础类添加新的功能。而桥接模式是存在已有的变化维度，且这个变化维度是有规律的，如变化维度可以是“红色，黄色，蓝色”等等，只是在两个变化维度中架设一座桥梁。然而装饰模式一般只有一个变化维度，而且这个变化维度是没有规律的。

6.和适配器模式的关系

 装饰模式和适配器模式都是“包装模式(Wrapper Pattern)”，它们都是通过封装其他对象达到设计的目的的，但是它们的形态有很大区别。

 

 

 

　　理想的装饰模式在对被装饰对象进行功能增强的同时，要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。而适配器模式则不然，一般而言，适配器模式并不要求对源对象的功能进行增强，但是会改变源对象的接口，以便和目标接口相符合。

 

 

 

　　装饰模式有透明和半透明两种，这两种的区别就在于装饰角色的接口与抽象构件角色的接口是否完全一致。透明的装饰模式也就是理想的装饰模式，要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。相反，如果装饰角色的接口与抽象构件角色接口不一致，也就是说装饰角色的接口比抽象构件角色的接口宽的话，装饰角色实际上已经成了一个适配器角色，这种装饰模式也是可以接受的，称为“半透明”的装饰模式，如下图所示。

 

 

 

 

 在适配器模式里面，适配器类的接口通常会与目标类的接口重叠，但往往并不完全相同。换言之，适配器类的接口会比被装饰的目标类接口宽。

 

显然，半透明的装饰模式实际上就是处于适配器模式与装饰模式之间的灰色地带。如果将装饰模式与适配器模式合并成为一个“包装模式”的话，那么半透明的装饰模式倒可以成为这种合并后的“包装模式”的代表。

 ————————————————

版权声明：本文为CSDN博主「林花谢了春红」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/a1610770854/article/details/53501089

9     (结构型)_代理模式

代理模式的定义：为其他对象提供一种代理以控制对这个对象的访问。在某些情况下，一个对象不适合或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。

 

 

 

组成：

抽象角色：通过接口或抽象类声明真实角色实现的业务方法。

代理角色：实现抽象角色，是真实角色的代理，通过真实角色的业务逻辑方法来实现抽象方法，并可以附加自己的操作。

真实角色：实现抽象角色，定义真实角色所要实现的业务逻辑，供代理角色调用。代理对象提供一个与目标对象相同的接口，以便可以在任何时候替代目标对象。代理对象通常在客户端调用传递给目标对象之前或之后，执行某个操作，而不是单纯地将调用传递给目标对象。

 

 

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78107933

 

10      (结构型)_享元模式

享元模式（英语：Flyweight Pattern）是一种软件设计模式。它使用共享物件，用来尽可能减少内存使用量以及分享资讯给尽可能多的相似物件；它适合用于只是因重复而导致使用无法令人接受的大量内存的大量物件。通常物件中的部分状态是可以分享。常见做法是把它们放在外部数据结构，当需要使用时再将它们传递给享元。

 

 

 

两个状态

      

      享元模式包含内蕴状态和外蕴状态：

内蕴状态存储在享元内部，不会随环境的改变而有所不同，是可以共享的

外蕴状态是不可以共享的，它随环境的改变而改变的，因此外蕴状态是由客户端来保持（因为环境的变化是由客户端引起的）。

 

具体实现：

 

 

 

 

 

享元角色类RealFlyweight有一个内蕴状态，用Character类型的innerStatus属性代表，它的值应当在享元对象被创建时赋予。所有的内蕴状态在对象创建之后，就不会再改变了。

 

如果一个享元对象有外蕴状态的话，所有的外部状态都必须存储在客户端，在使用享元对象时，再由客户端传入享元对象。这里只有一个外蕴状态，operation(status)方法的参数status就是由外部传入的外蕴状态。

 ————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78147100

享元模式的优缺点

　　享元模式的优点在于它大幅度地降低内存中对象的数量。但是，它做到这一点所付出的代价也是很高的：

 

　　●　　享元模式使得系统更加复杂。为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。

 

　　●　　享元模式将享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。

 ————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78147100

11  （结构型）外观模式

为子系统提供统一的入口，封装子系统的复杂性，便于客户端调用。

12      (结构型)_适配器模式

1. 对象适配：已有基础类直接持有（聚合）需要的对象（可以是多个），然后调用此对象的行为，以对外实现行为。
2. 类适配：新增类继承新增扩展接口（需要的行为）和已有基础类，然后实现接口。

13      (结构型)_组合模式

组合模式，将对象组合成树形结构以表示“部分-整体”的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。掌握组合模式的重点是要理解清楚 “部分/整体” 还有 ”单个对象“ 与 "组合对象" 的含义。

有时候又叫做部分-整体模式，它使我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。

 

涉及角色

1.Component 是组合中的对象声明接口，在适当的情况下，实现所有类共有接口的默认行为。声明一个接口用于访问和管理Component子部件。

2.Leaf 在组合中表示叶子结点对象，叶子结点没有子结点。

3.Composite 定义有枝节点行为，用来存储子部件，在Component接口中实现与子部件有关操作，如增加(add)和删除(remove)等。

适用性

以下情况下适用组合模式：

1．你想表示对象的部分-整体层次结构

2．你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78063578

14      (行为型)_责任链模式

责任链模式是一种设计模式。在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。

核心：很多对象由每一个对象对其下家的引用而连接起来形成一条链。下家的设定由使用者自己动态指定。

 

 

责任链模式涉及到的角色：

●　抽象处理者(Handler)角色：定义出一个处理请求的接口。如果需要，接口可以定义 出一个方法以设定和返回对下家的引用。这个角色通常由一个Java抽象类或者Java接口实现。抽象方法handleRequest()规范了子类处理请求的操作。

●　具体处理者(RealHandler)角色：具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给下家。由于具体处理者持有对下家的引用，因此，如果需要，具体处理者可以访问下家。

 

标黄部分表示：可以设定或返回下家。

红色箭头表示传递给下家。

 ————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78180800

 

15      (行为型)_命令模式

在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，实现二者之间的松耦合。这就是命令模式（Command Pattern）

 

核心：请求者（持有命令）可以发起不同的命令，命令持有具体的命令接受者，命令的exe由具体的接受者完成。

 

 

 

模式说明

 

1.命令模式的本质是对命令进行封装，将发出命令的责任和执行命令的责任分割开。

2.每一个命令都是一个操作：请求的一方发出请求，要求执行一个操作；接收的一方收到请求，并执行操作。

3.命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。

4.命令模式使请求本身成为一个对象，这个对象和其他对象一样可以被存储和传递。

5.命令模式的关键在于引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。

 

 

 

相关角色

 

命令模式涉及到五个角色，它们分别是：

　　●　　客户端(Client)角色：创建一个具体命令(ConcreteCommand)对象并确定其接收者。

　　●　　命令(Command)角色：声明了一个给所有具体命令类的抽象接口。

　　●　　具体命令(ConcreteCommand)角色：定义一个接收者和行为之间的弱耦合；实现execute()方法，负责调用接收者的相应操作。execute()方法通常叫做执行方法。

　　●　　请求者(Invoker)角色：负责调用命令对象执行请求，相关的方法叫做行动方法。

　　●　　接收者(Receiver)角色：负责具体实施和执行一个请求。任何一个类都可以成为接收者，实施和执行请求的方法叫做行动方法。

 

 

 ————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78182446

命令模式适用场景：

 

 

1.系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。

2.系统需要在不同的时间指定请求、将请求排队和执行请求。

3.系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。

4.系统需要将一组操作组合在一起，即支持宏命令。

 

优缺点：

优点：

1.降低对象之间的耦合度。

2.新的命令可以很容易地加入到系统中。

3.可以比较容易地设计一个组合命令。

4.调用同一方法实现不同的功能。

 

缺点：

使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个命令都需要设计一个具体命令类，因此某些系统可能需要大量具体命令类，这将影响命令模式的使用。

16       (行为型)_迭代模式

迭代器模式（Iterator），提供一种方法顺序访问一个聚合对象中的各种元素，而又不暴露该对象的内部表示。

 

 

 

适用性

 

访问一个聚合对象的内容而无需暴露它的内部表示

支持对聚合对象的多种遍历

为遍历不同的聚合结构提供一个统一的接口

 

 

 

迭代子模式涉及的角色：

● 抽象迭代子(Iterator)角色：此抽象角色定义出遍历元素所需的接口。  

● 具体迭代子(RealIterator)角色：此角色实现了Iterator接口，并保持迭代过程中的游标位置。 

● 聚集(Aggregate)角色：此抽象角色给出创建迭代子(Iterator)对象的接口。 

● 具体聚集(RealAggregate)角色：实现了创建迭代子(Iterator)对象的接口，返回一个合适的具体迭代子实例。

● 客户端(Client)角色：持有对聚集及其迭代子对象的引用，调用迭代子对象的迭代接口，也有可能通过迭代子操作聚集元素的增加和删除。

 

 

 

具体实现：

 

 

 ————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78189643

迭代模式效果：

 

它支持以不同的方式遍历一个聚合。

迭代器简化了聚合的接口。

在同一个聚合上可以有多个遍历。

 

迭代子模式的优点

1）迭代子模式简化了聚集的接口。迭代子具备了一个遍历接口，这样聚集的接口就不必具备遍历接口。

 

2）每一个聚集对象都可以有一个或多个迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。因此，一个聚集对象可以同时有几个迭代在进行之中。

 

3）由于遍历算法被封装在迭代子角色里面，因此迭代的算法可以独立于聚集角色变化。

 

 

 

 ————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78189643

17      (行为型)_中介者模式

用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显示地相互引用，从而使得其耦合松散，而且可以独立地改变它们之间地交互，从相互引用网状结构变成以中介者为中心地星型结构。

 

客户—中介---◇各个操作类

与代理的区别：

代理与真实角色是1对1的关系，且操作行为相同。

中介与操作类是1对多的关系，且操作行为不同。

18  （行为模式）备忘录模式

备忘录模式是一种软件设计模式：在不破坏封闭的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。

 

 

 

 

 

相关角色

 

1.Originator(发起人)：负责创建一个备忘录Memento，用以记录当前时刻自身的内部状态，并可使用备忘录恢复内部状态。Originator可以根据需要决定Memento存储自己的哪些内部状态。

 

2.Memento(备忘录)：负责存储Originator对象的内部状态，并可以防止Originator以外的其他对象访问备忘录。备忘录有两个接口：Caretaker只能看到备忘录的窄接口，他只能将备忘录传递给其他对象。Originator却可看到备忘录的宽接口，允许它访问返回到先前状态所需要的所有数据。

 

3.Caretaker(管理者):负责备忘录Memento，不能对Memento的内容进行访问或者操作。

 

 

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78213896

 

19      (行为型)_观察者模式

核心:被观察者改变时，更新观察者（触发 持有的所有观察者 更新或操作）。

 

观察者模式（有时又被称为发布（publish ）-订阅（Subscribe）模式、模型-视图（View）模式、源-收听者(Listener)模式或从属者模式）是软件设计模式的一种。在此种模式中，一个目标物件管理所有相依于它的观察者物件，并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实现事件处理系统。

 

 

 

 

相关角色

 

观察者模式主要包括以下角色：

 

1、抽象主题(Subject)角色：抽象主题角色把所有对观察者对象的引用保存在一个聚集（比如ArrayList对象）里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象，抽象主题角色又叫做抽象被观察者(Observable)角色。

2、具体主题(RealSubject)角色：将有关状态存入具体观察者对象；在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色又叫做具体被观察者(Concrete Observable)角色。

3、抽象观察者(Observer)角色：为所有的具体观察者定义一个接口，在得到主题的通知时更新自己，这个接口叫做更新接口。

具体观察者(RealObserver)角色：存储与主题的状态自恰的状态。具体观察者角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态 像协调。如果需要，具体观察者角色可以保持一个指向具体主题对象的引用。

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78219450

 

20      (行为型)_状态模式

(源于Design Pattern)：当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。

状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式的示意性类图如下所示：

 

 

 

 

 

相关角色

 

状态模式所涉及到的角色有：

●环境(Context)角色，也成上下文：定义客户端所感兴趣的接口，并且保留一个具体状态类的实例。这个具体状态类的实例给出此环境对象的现有状态。

●抽象状态(State)角色：定义一个接口，用以封装环境（Context）对象的一个特定的状态所对应的行为。

●具体状态(RealState)角色：每一个具体状态类都实现了环境（Context）的一个状态所对应的行为。

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78223507

 

 

适用性

 

1.一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为。

2.一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态,这个状态通常用一个或多个枚举常量表示,通常,有多个操作包含这一相同的条件结构。State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78223507

 

21      (行为型)_策略模式

策略模式是指对一系列的算法定义，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。

 

策略模式是对算法的包装，是把使用算法的责任和算法本身分割开来，委派给不同的对象管理。策略模式通常把一个系列的算法包装到一系列的策略类里面，作为一个抽象策略类的子类。用一句话来说，就是：“准备一组算法，并将每一个算法封装起来，使得它们可以互换”。

 

 

策略模式的优点有：策略模式提供了管理相关的算法族的办法、策略模式提供了可以替换继承关系的办法、使用策略模式可以避免使用多重条件转移语句。

 

 

 

 

 

相关角色

 

策略模式涉及到三个角色：

1、环境(Context)角色：持有一个Strategy的引用。

2、抽象策略(Strategy)角色：这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。

3、具体策略实现(RealStrategy)角色：包装了相关的算法或行为。

 

 

 

与状态模式的区别：策略模式中上下文中只会选定一种策略，而状态模式中：上下文中可以不断切换状态。

 

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78225882

 

22      (行为型)_模版方法模式

22.1   核心：父类定框架（或流程），子类定细节（框架或流程中的各部分的实现）。

模板方法模式是所有模式中最为常见的几个模式之一，是基于继承的代码复用的基本技术。

模板方法模式需要开发抽象类和具体子类的设计师之间的协作。它是类的行为模式，准备一个抽象类，将部分逻辑以具体方法以及具体构造函数的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。这就是模板方法模式的用意，模板方法所代表的行为称为顶级行为，其逻辑称为顶级逻辑。

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78227316

 

 

 

使用说明

 

在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使的子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。模版中将主要的方法定义为final，防止子类修改算法骨架，将子类必须实现的方法定义为abstract。而普通的方法（无final或abstract修饰）则称之为钩子。

 

 

 

相关角色

 

1、抽象模板角色：

定义了一个或多个抽象操作，以便让子类实现。这些抽象操作叫做基本操作，它们是一个顶级逻辑的组成步骤。

定义并实现了一个模板方法。这个模板方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。

 

2、具体模板角色(模版子类)：

实现父类所定义的一个或多个抽象方法，它们是一个顶级逻辑的组成步骤。

每一个抽象模板角色都可以有任意多个具体模板角色与之对应，而每一个具体模板角色都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。

 

 

 

模板模式的关键是：子类可以置换掉父类的可变部分，但是子类却不可以改变模板方法所代表的顶级逻辑。

每当定义一个新的子类时，应当考虑哪些操作是必须置换掉的，哪些操作是可以置换掉的，以及哪些操作是不可以置换掉的。使用模板模式可以使这些责任变得清晰。

 

 

 

优缺点：

 

优点：

1)模板方法模式在一个类中形式化地定义算法，而由它的子类实现细节的处理。

2)模板方法是一种代码复用的基本技术。它们在类库中尤为重要，它们提取了类库中的公共行为。

3)模板方法模式导致一种反向的控制结构，通过对子类的扩展增加新的行为，符合“开闭原则”。

 

缺点：

1)每个不同的实现都需要定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象。

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78227316

 

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

 

原文链接：https://blog.csdn.net/vtopqx/article/details/78227316

 

23      (行为型)_访问者模式

访问者模式（Visitor Pattern）是GoF提出的23种设计模式中的一种，属于行为模式。据《大话设计模式》中说算是最复杂也是最难以理解的一种模式了。

定义（源于GoF《Design Pattern》）：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。

从定义可以看出结构对象是使用访问者模式必备条件，而且这个结构对象必须存在遍历自身各个对象的方法。这便类似于Java语言当中的collection概念了。

 

 

 

 

 

相关角色

 

1.抽象访问者Visitor：抽象类或者接口，声明访问者可以访问哪些元素，具体到程序中就是visit方法中的参数定义哪些对象是可以被访问的。

2.具体访问者ConcreteVisitor.：实现抽象访问者所声明的方法，它影响到访问者访问到一个类后该干什么，要做什么事情。

3.抽象元素类Element：接口或者抽象类，声明接受哪一类访问者访问，程序上是通过accept方法中的参数来定义的。抽象元素一般有两类方法，一部分是本身的业务逻辑，另外就是允许接收哪类访问者来访问。

4.具体元素类ObjectStructure：实现抽象元素类所声明的accept方法，通常都是visitor.visit(this)，基本上已经形成一种定式了。

结构对象：一个元素的容器，一般包含一个容纳多个不同类、不同接口的容器，如List、Set、Map等，在项目中一般很少抽象出这个角色。

 

核心：

访问者持有被访问者，被访问者持有访问者。

被访问者接受访问时，调用访问者访问自己。访问者访问时，调用被访问者完成对应操作。

 

观察者模式优缺点

 

优点

 

1）符合单一职责原则：凡是适用访问者模式的场景中，元素类中需要封装在访问者中的操作必定是与元素类本身关系不大且是易变的操作，使用访问者模式一方面符合单一职责原则，另一方面，因为被封装的操作通常来说都是易变的，所以当发生变化时，就可以在不改变元素类本身的前提下，实现对变化部分的扩展。

2）扩展性良好：元素类可以通过接受不同的访问者来实现对不同操作的扩展。

 

缺点

 

1）对象结构变化很困难

不适用于对象结构中的类经常变化的情况，因为对象结构发生了改变，访问者的接口和访问者的实现都要发生相应的改变，代价太高。

2）破坏封装

访问者模式通常需要对象结构开放内部数据给访问者和ObjectStructrue，这破坏了对象的封装性。

 

 

 

适用情况

 

1） 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。

2） 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Visitor模式使得你可以将相关的操作集中起来 定义在一个类中。

3） 当该对象结构被很多应用共享时，用Visitor模式让每个应用仅包含需要用到的操作。

4）定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。

————————————————

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78235230

版权声明：本文为CSDN博主「漫天雪_昆仑巅」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vtopqx/article/details/78235230

 

24      行为型- 解释器模式（Interpreter）

核心：抽象解释器，实现具体场景的不同解释类。使用时，调用不同的解释类进行解释。可以动态修改和增加解释类。

 

给定一种语言，定义它的方法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子

 

 

角色

抽象解释器（AbstractExpression）：声明一个抽象解释操作

 

终结符表达式（TerminalExpression）：实现文法中与终结符相关联的解释操作

 

非终结符表达式（NonterminalExpression）：实现了文法中非终结符的解释操作，可用于文法中的连接符、运算符等

 

上下文/环境（Context）：它包含了解释器之外的全局信息

 

优点

解释器是可以作为一个语法分析工具，扩展性很好，修改语法规则，只需要修改相应的终结符类就可以，如果要修改语法，则修改相应的非终结符类即可

缺点

语法较为复杂时，类太多

适用场景

重复发生的有规律的问题，如加减乘除表达式

————————————————

版权声明：本文为CSDN博主「jx_870915876」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/jx_870915876/article/details/52331956