深入浅出设计模式（十四）：23种设计模式概念总结

创建型模式 5种

1.单例模式（Singleton）

单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。

eg.

数据库。连接数据库很耗时，不停地新建连接会影响性能，用单例模式，一个数据库建立完成后，可以提供给后面的所有对数据库的操作使用，保证数据库的连接在系统运行时只有一个实例存在。随着业务复杂，数据库连接池技术应运而生，也需要单例模式。

Runtime类。与JVM运行时环境有关，可获取JVM虚拟内存，垃圾回收，加载动态库等，这个类就是单例模式的典型应用。可以通过getRuntime方法获取当前运行，应用程序不能创建自己的Runtime类。

日志。如java提供的logging，开源的Log4j。

2.简单工厂模式（Simple Factory）

将对象的产生细节进行隐藏，客户端只负责调用即可。简单工厂模式又叫静态工厂模式，它定义了一个具体的工厂类来负责类的创建。缺点是当产品修改时，工厂类也要做相应的修改；如果创建的类很多，这个工厂类就会异常庞大。

标准23种设计模式中无此模式。

eg.

Spring就使用了工厂模式来创建bean，通过xml或者properties进行配置.

2.工厂方法模式（Factory Method）

如果每一个产品都有一个具体的工厂来创建，把简单工厂模式中那个庞大的工厂类拆分成一个个小工厂类，这样每个具体的小工厂类只负责单独对象的创建，职责就变小了。

核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

eg.

在Spring中，通过配置即可实现依赖注入，然后通过工厂方法模式来创建bean。“实现必须依赖于抽象，而不是抽象依赖实现”就是“反向控制”的一种表现方式。

比如取得数据的方式可能有3种，分别来自数据库、XML、File：

再比如spring依赖注入的3种方式：接口注入，Set注入，构造器注入。
BeanFactory接口是Spring提供的工厂bean的标准接口，使用BeanFactory接口可以简化工厂bean的开发和配置。ApplicationContext建立在BeanFactory之上，并增加了其他功能，比如更易于同Spring AOP整合。

Spring的IOC功能实际上就是ApplicationContext组件结合BeanFactory组件共同实现的。

3.抽象工厂模式(Abstract Factory)

抽象工厂模式相对于工厂方法模式来说，就是工厂方法模式是针对一个产品系列的，而抽象工厂模式是针对多个产品系列的。

4.原型模式（Prototype）

通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。缺点是每一个类都必须配备一个克隆方法。

5.创建者模式(Builder)

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同表示，而且客户端不用知道对象的构建细节。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部的细节。建造模式可以强制实行一种分步骤进行的建造过程。

抽象工厂模式中了，对象的创建和组装都放在工厂类里，如果组装变得复杂，则工厂类异常庞大。而创建者模式中，工厂类就只负责对象的创建，不负责组装，由Director进行组装。两个模式很相似，只是创建者模式更进一步地实现了类的单一职责。

---

结构型模式 7种

6.适配器模式(Adapter)

就是一个系统接口转换成另外一种形式，从而使原来不能直接调用的接口，变得可以调用。适配类可以根据参数返还一个合适的实例给客户端。

在程序开发中，当一个系统需要使用另一个系统提供的外部接口，而这个外部接口与目前系统使用的接口不兼容时，就需要使用适配器模式。

eg.

笔记本电源上，经常会看到一个“适配器”字样，这个电源适配器就是将插座上的220V的电压转换成笔记本电脑所需的20V电压。

财务系统要使用人事系统的接口，而人事系统来不及写，财务系统又不能停下来等，这时两种解决办法：一种是双方事先定好要提供的接口方法，包括方法名、参数、返回值等；另一种是双方各自开发自己的程序，等将来提供了接口再进行整合，此时就需要适配器模式进行开发

有时候需要使用外部购买的系统提供的接口，或者使用很久以前的接口（已经不再维护），或者系统对方不提供源代码，这时需适配器模式将购买的系统接口转成自己需要的接口

如java的接口定义了8个方法，而一个客户端使用2个，另一个客户端只是用1个，如果将这8个方法都在实现类里覆写一遍，将会非常麻烦，此时可用适配器模式

适配器模式在StringReader, StringWriter, CharArrayReader, CharArrayWriter广泛应用。如Reader和Writer是用来进行字符的输入和输出的，StringReader和StringWriter分别继承Reader、Writer，将String和Reader、Writer进行适配。

在Spring的AOP中，由于Advisor需要的是MethodInterceptor对象，所有每一个Advisor中的Advice都要适配成对应的MethodInterceptor对象。

在Spring的ORM包中，对于JPA的支持也是采用了适配器模式，首先定义了一个抽象类的JpaVendorAdapter，然后不同的持久层框架都继承了此类

适配器模式在JUnit中实际应用。通俗而言，就是要适配成TestCase类。重点去看TestCase的runTest()方法。在这里目标接口Target和适配器Adapter变成了同一个类TestCase，主要了利用了JAVA反射机制。

7.门面模式（Facade）

到蛋糕店买蛋糕，不需要知道蛋糕怎么制作，蛋糕房就是蛋糕的门面，屏蔽了制作蛋糕的细节，门面模式又称为外观模式。实际开发中，屏蔽了子模块内部的实现细节，只是将客户端需要的接口提供给客户。

外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。

eg.

网上商城有银行支付功能，而银行肯定不能将后台的数据库直接开放给网上商城使用，不同银行提供相应的支付接口，这样的支付接口对于银行而言就是一个门面。

薪资系统开发中，计算每个月薪酬时，要获取很多数据库信息，如果每个员工都这样到每个不同子模块表去获取，则暴露细节太多，如果后台表变化，则需要修改薪资计算的代码，明显不符合松耦合的设计原则，因此需要门面模式，屏蔽细节。

在框架设计中，比如Spring、Struts、Hibernate等，很多地方需要读取xml文件，此时就应该把读取xml配置文件的代码抽取出来，形成统一的接口。

软件开发一般需要对数据库进行操作，直接使用JAVA提供的JDBC往往会比较麻烦，因此需要对JAVA提供的JDBC进行封装，提供一个公用的工具类，这就是门面模式。已有的工具类如Hibernate、Spring JDBC等。

8.代理模式（Proxy）

我们买房子办理贷款时可以自己到银行办理，但是手续很多，也可以找相应的代理公司，这样我们什么都不用管。代理模式就是给一个对象提供一个代理对象，由这个代理对象控制对原对象的引用。

代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。

eg.

在程序开发中，经常会遇到一些和具体业务逻辑无关的代码控制，比如日志、权限、事务处理等，每段代码都添加日志、权限、事务处理的代码编写起来很麻烦，如果有一个代理类，统一进行这些额外处理，程序人员就可以将精力放在业务逻辑的代码编写中。

动态代理，Proxy，InvocationHandler，Method。

面向方面的程序编程。AOP就是要分离那种与业务不相关的代码，通过另一种方式实现对业务代码的控制，而业务代码本身并不改变，这恰恰是代理模式的好时机，因为当系统需要对某个对象进行额外控制时，就需要使用代理模式。通过JAVA的动态代理机制，就可以很容易实现AOP的思想。Spring的AOP也是建立在java的代理机制上，主要类是JdkDynamicAopProxy。Spring还有另一种代理方式叫Cglib2AopProxy。

代理模式在struts2中的实际应用。

在Struts2中，一个重要的类是org.apache.struts2.dispatcher.FilterDispatcher，用户通过浏览器提交一个HttpServletRequest请求后，请求被在web.xml中定义的过滤器FilterDispatcher拦截，在FilterDispatcher过滤器中首先询问ActionMapper是否需要调用某个Action来处理请求，如果ActionMapper决定调用某个某个Action，FilterDispatcher则把请求的处理交给ActionProxy，ActionProxy通过配置文件struts.xml找到需要调用的Action类，然后ActionProxy创建一个ActionInvocation实例并调用该Action，但在调用之前，ActionInvocation会根据加载Action相关的所有Interceptor，等Action执行完毕，ActionInvocation负责根据struts.xml中的配置找到对应的返回Result。

在Struts2中，拦截器其实是AOP的一种实现方式，通过拦截器可以在Action执行的前后处理一些相应的操作。

9.合成模式（Composite）

合成模式又叫树形模式，就是把部分和整体的关系用树形结构表示，使得客户端对单个对象和组合对象的使用具有一致性。
合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。

eg.

比如将一个文件从C盘复制到D盘，也可以将一个文件夹从C盘复制到D盘中，不管是哪种方式，我们的操作都是一样的，而且文件夹下的所有文件都会同时复制过去。

比如团购方式，对于商家而言，不管消费者是单独购买还是团购，处理方式都是一样，就是收钱发货。

合成模式在JUnit的实际应用。TestCase是对单个类编写的测试类，而TestSuite是对一组TestCase的集合进行测试，而且这个集合里面也可以包含TestSuite，这样运行一个TestSuite会将其包含的TestCase全部运行。不管是TestCase还是TestSuite，JUnit都会按照同样的方式执行，这就是合成模式。

10.享元模式（Flyweight）

在前面讲解单例模式时，一个类只有一个唯一的对象，也就是说，不管new多少次，只需要创建这个类的一个对象，如果不采用单例模式，每new一次，就会创建一个对象，这对于系统消耗太大，这时就需要使用享元模式。

享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。

eg.

在程序开发中，经常会使用到数据库，如果采用单例模式，整个系统只使用一个数据库连接，当用户并发量很大时，系统将会变得非常慢，如果用户每一次请求都创建一个新的连接，每次都会花费0.01s-1s的时间，频繁进行数据库连接操作势必占用很多系统资源，网站的响应速度必定下降，严重的甚至会造成服务器的崩溃。这时就要用到享元模式，数据库连接池就是享元模式的典型应用。

还有比如String s1 = “abc”; String s2 = “abc”; 输出s1==s2为true，也就是说虽然是两个字符串，但引用了相同的地址，这不难理解，因为java会频繁地使用这些基本类型和字符串类型，如果每次赋值都创建一个新的对象，内存的开销极大，所以要用享元模式。

11.装饰模式（Decorator）

在程序开发中，有时候开发人员会使用继承来扩展对象的功能，用户的需求是多变的，也就造成继承会造成代码的大范围改动，其实扩展对象的功能，采用组合比继承要好很多，当用户需求变动时，只需要将对象间的组合发生变化就可以了。

装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。

eg.

装饰就是物品原来的功能并没有改变，只是在原来的功能上添加了一些新的功能，就好像是进行了装饰一样。其实关键是要理解装饰模式的本质，是为了扩充软件的功能，但又不改变软件原本的功能。

用装饰模式的主要目的也是为了是两个关联类之间解耦，以方便组合一些新的功能，就好像进行了包装一样。

比如开发超时收银系统时，最主要的是收银功能，但超市经常会遇到打折、赠送等活动，此时收银功能还被别的程序使用，所以不能直接在该方法上修改。这里就用到装饰模式（当然第一想到的是继承）

junit用到装饰模式，TestDecorator是Test的装饰类，RepeatedTest类是TestDecorator的子类，增加了重复执行的功能，TestSetup类是TestDecorator的子类，增加了在执行完毕前后可进行一些初始化和消耗动作。

在java的流的应用。一般使用StringReader要增加缓存功能，BufferedReader类就是这样的装饰类，BufferedReader将Reader的子类StringReader的数据放入缓存，然后再操作read，从缓存中读取。其实java I/O 库中的所有输入流、输出流都采用了装饰器模式，可以无限次地进行装饰转换，目的就是得到自己想要的数据类型的流对象。

12.桥接模式（Bridge）

前面几章讲解的结构型设计模式也都是告诉开发人员如何使用组合来代替继承，桥模式也不例外，桥模式将抽象与其实现解耦，使它们可以分别独立地变化，是继承的一种代替方式。

将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。

---

行为型模式，共11种

13.策略模式（Strategy）

策略模式就是定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换，比如在人力资源系统的薪资计算时，针对不同的人员会有不同的薪资计算方法，将这些算法分离出来，就是策略模式，策略模式让算法独立于使用它的客户而独立变化。

策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。

eg.

田忌通过安排不同的马来进行比赛，从而将劣势变为优势，并取得了最终的胜利，做一件事情有很多方法，同样都可以完成一件事情，但达到的效果可能不一样，这就是策略模式。

策略模式就是提供相同的接口，开发人员根据响应的接口实现不同的策略，然后根据不同的情况选用不同的策略，从而实现了客户端代码不用修改，只用替换不同的策略实现类即可。

策略模式在Spring中的实际应用。Spring把所有能记录信息的文件，如各种类型的文件、二进制流等都称为资源，Spring改进了Java资源访问的策略，它为资源访问提供了一个Resource接口，Resource接口是具体资源访问策略的抽象，也是所有资源访问类所实现的接口。

在Spring中，Bean的初始化也用到了策略模式，具体就是SimpleInstantiationStrategy类，可以去看看源码。

14.迭代器模式（Iterator）

在软件开发中，经常需要将某一类对象放在一个集合里，或者放在容器里，这个时候通常需要对集合或容器里的对象进行访问，很明显，对集合或容器里对象的访问必须涉及遍历，这就是迭代器模式。

顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代器模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。

eg.

迭代器模式就是提供了一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部标识，迭代器模式分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可以让外部代码透明地访问集合内部的数据。

看java 迭代器源码。

15.模版方法模式（Template Method）

模版方法模式在程序开发中经常使用，目的就是定义一系列算法执行的顺序，而把具体算法的实现在子类中完成，在很多框架（比如Spring、JUnit）中都实现了模版方法模式。

模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。

和策略模式很像，但模版模式规定了执行方法的顺序

eg.

比如新闻发布系统中，对于查看新闻的页面来说，该新闻的抬头、结尾都有一定的格式，变化的只是新闻的内容，通常情况下，开发人员会使用模版技术，将新闻的抬头和结尾都固定，只改变新闻的内容，这样能够极大提高开发效率。

再比如其后介绍的命令模式，它是将用户事先设定好的命令存储起来，然后在指定的时间里按照一定的顺序将命令取出来执行，可以看出，在实际的应用开发中，命令模式与职责链模式可以很好的结合起来，对于用户的命令，可以通过命令模式进行存储，然后通过职责链模式，再将命令按照一定的顺序进行执行。

模版方法模式在JUnit中的使用。源码比较简单，模版方法模式主要体现在TestCase类的runBare()方法中定义了顺序，先setUp()，再runTest（），再tearDown（）。

模版方法模式在Servlet中的使用。在HttpServlet中有几个重要的方法，一个是doPost()方法，一个是doGet()方法，还有一个是Service()方法。 Servlet是由WebLogic之类的Servlet容器来调用处理器请求的，Servlet定义了一个处理模版，实现Servlet只需继承Servlet并实现doGet、doPost等方法即可。看HttpServlet源码。

模版方法模式在数据库的实际应用。不管哪种持久层的操作方法，创建连接、关闭连接都是一致的，按照相同顺序执行，这就是模版方法模式的应用。Spring采用开放式处理方式，因为与Jpa、Jdo、ibatis、hibernate很好结合。看JpaTemplate 、JdoTemplate、SqlMapClientTemplate源码。

16.中介者模式（Mediator）

中介者模式又叫调停者模式，比如说租房中介，通过中介，租房者和房东之间就建立了很好的联系，中介者模式采用的就是这个道理，用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式的相互引用。

eg.

mvc框架的控制层就是中介者模式的应用实例。

目前软件外包业务发达，很多人都在网上发布软件或项目外包的任务供软件开发人员选择，这种类型的网站就好像一个中介一样，类似还有淘宝，卖家可以在网上发布需要售卖的商品，消费者可以进入网站查找自己需要购买的商品，淘宝在这就承担了一个中介的工作，如果遇到了买卖双方的纠纷，淘宝还要承担调停者的角色。

在消息队列的实际应用。

17.访问者模式（Vistor）

访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。

eg.

类似银行办理业务，需要排号，银行窗口叫号来办理相应的业务。访问者模式在呼叫中心也有着广泛应用，当客户打电话进去时，系统会自动寻找目前还在待机的电话，然后客户与其接通。

比如超市会员，可分为不打折会员、打9折会员、打8折会员。如果不用访问者模式，则定义的访问者类中要很多if语句判断是哪种会员，再做操作。

18.职责链模式（Chain of Responsibility）

职责链模式在程序应用中十分广泛，经常使用在公文审批、出差报支等地方，职责链模式的作用就是将对象各自处理的职责分开，虽然职责很多，但最终只有一个职责进行处理。

很多对象由每一个对象对其下家的引用而接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。

eg.

比如在玩纸牌，当一个人出牌后，接下来将按照顺序进行询问下一个人是否需要出牌压住上一个人出的牌，如果询问一圈后，无人出牌，则该人继续出牌，然后按照同样规则继续询问，直到有人压住该人的牌，这就好像是一个职责链一样。

再比如“击鼓传花”游戏，在游戏中，一圈人随着击鼓的声音将花不断地往下传，这和职责链也是类似的，谁也不想让花停留在自己的手里，谁都想传递给下一个人，但最终花会落在一个人手里，也就是说虽然前面的人都不想承担这个职责，但是最后还是会有一个人承担受惩罚的职责。

职责链模式在Struts的应用。拦截器（Interceptor）是Struts2的核心组成部分。当需要扩展Struts2功能时， 只需提供对应拦截器，并将它配置在Struts2容器中即可。

19.状态模式（State）

在上面的职责链模式中，是将条件语句改为多个职责类进行处理，但每个职责类只负责处理一件事情，如果不是自己处理，则自动转给下一个职责类，有一种情况为在转给下一个职责类进行处理前，需要修改当前状态，此时就需要用到状态模式。

状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。

eg.

比如电梯运行过程中，有着各种各样的状态，比如电梯厢内的检修开关置于“正常”、自动开关置于“运行”位置时，电梯进入自动工作状态，当电梯内有人选择楼层后，电梯可自动关门启动运行；当遇火警信号后，消防员将一楼的消防开关置于运行位置，若此电梯正在上行，则电梯就会在就近的楼层停。

在企业的应用中，公文审批、报支单审批、物资计量也是典型的状态控制方式。

20.解释器模式（Interpreter）

解释器模式在软件开发中应用较少，它主要应用于底层的编程语言设计上。

给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。

eg.

人类很早以前都希望能够通过语音来对电视、洗衣机等电器进行控制，一直以来，这个过程步履艰难，直到iPhone4s的出现，其siri功能会将用户讲的语音进行翻译，从而解释使用者的意思，并根据使用者的请求，反馈相应的信息，这就是解释器模式在手机中的实际应用。

在日常中使用的计算器，根据用户输入的数字和运算符号，对表达式进行解析，最终得出计算结果，所谓解析，其实就是对用户输入的字符进行解释，分析出哪些是数字，哪些是运算符，是否有运算符优先级的处理等，这些都是解释器模式需要做的事情。

21.观察者模式（Observer）

观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。

eg.

每个月当银行发放工资时，都会有短信自动通知员工，员工就相当于观察者，账户就是被观察者，当账户余额有变动时，会自动通知观察者，这就是观察者模式的实际应用。

比如银行的手机提醒功能，当账户余额变动时，只要将手机号注册到银行系统中，就会自动通知到手机上。

目前网上商城比较流行，当有新的货物或货物价格有变化时，只要将电子邮件注册到网站上，就可以自动收到新货物或价格变动的邮件。

观察者模式在Spring中的实现。在Spring中，任何一个类要能够称为事件源，首先得继承ApplicationContentextAware并在响应的方法中产生事件对象，并通过publishEvent方法对事件进行传播，另外监听器必须实现ApplicationListener接口。

22.命令模式（Command）

命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。

eg.

到银行办理业务时，通常要先到取号机进行取号，然后到相应的窗口办理业务，这里的取号机就是下达具体某个窗口执行指令的命令类。

再比如全自动洗衣机，可以自行设定洗涤时间，到时间洗衣机就能自动洗涤、漂洗，只需要选择相应的指令即可。

命令模式在Struts中的实际应用。 Action就是命令模式的命令接口，根据不同的请求去创建不同的Action，然后执行execute()方法，ActionInvocation接口就是命令模式的调用者，其有一个具体的实现类叫DefaultActionInvocation。

23.备忘录模式（Memento）

在软件构建过程中，某些对象的状态在转换过程中，可能由于某些需要，要求程序能够回溯到对象之前处于某个点时的状态。

备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。

eg.

在企业交往过程中，经常会看到某某企业双方签署了备忘录，以供以后进行查询。软件开发中，如人力资源系统，在录入当前人资料时，突然发现前一个人的资料录入错误，此时就需要将前面一个人的资料恢复过来，然后进行修改，此时就需要使用备忘录模式。

在使用word编辑文档时，经常会遇到电脑死机或停电的情况，此时，如果重新打开word，就会发现word已经记录了在停电前正在编辑的文档，并且会询问用户是否需要恢复到以前的文档。

在网站应用中，经常会用到数据的备份和恢复，每天进行一次增量备份，每周进行一次全面备份，以保证数据的完整和安全性，一边必要时进行数据恢复。