18.3　模 式 讲 解

18.3.1　认识状态模式

1．状态和行为

所谓对象的状态，通常指的就是对象实例的属性的值；而行为指的就是对象的功能，再具体点说，行为大多可以对应到方法上。

状态模式的功能就是分离状态的行为，通过维护状态的变化，来调用不同状态对应的不同功能。

也就是说，状态和行为是相关联的，它们的关系可以描述为：状态决定行为。

由于状态是在运行期被改变的，因此行为也会在运行期根据状态的改变而改变，看起来，同一个对象，在不同的运行时刻，行为是不一样的，就像是类被修改了一样。

2．行为的平行性

注意是平行性而不是平等性。所谓平行性指的是各个状态的行为所处的层次是一样的，相互是独立的、没有关联的，是根据不同的状态来决定到底走平行线的哪一条。行为是不同的，当然对应的实现也是不同的，相互之间是不可替换的，如图18.3所示。

图18.3　状态的平行性示意图

而平等性强调的是可替换性，大家是同一行为的不同描述或实现，因此在同一个行为发生的时候，可以根据条件挑选任意一个实现来进行相应的处理，如图18.4所示。

图18.4　平等性的示意图

大家可能会发现状态模式的结构和策略模式的结构完全一样，但是，它们的目的、实现、本质却是完全不一样的。还有行为之间的特性也是状态模式和策略模式一个很重要的区别，状态模式的行为是平行性的，不可相互替换的；而策略模式的行为是平等性的，是可以相互替换的。

3．上下文和状态处理对象

在状态模式中，上下文是持有状态的对象，但是上下文自身并不处理跟状态相关的行为，而是把处理状态的功能委托给了状态对应的状态处理类来处理。

在具体的状态处理类中经常需要获取上下文自身的数据，甚至在必要的时候会回调上下文的方法，因此，通常将上下文自身当作一个参数传递给具体的状态处理类。

客户端一般只和上下文交互。客户端可以用状态对象来配置一个上下文，一旦配置完毕，就不再需要和状态对象打交道了。客户端通常不负责运行期间状态的维护，也不负责决定后续到底使用哪一个具体的状态处理对象。

4．不完美的OCP体验

好了，已经使用状态模式重写了前面的示例，那么到底能不能解决前面提出的问题呢？也就是修改和扩展是否方便？一起来看看。

先修改已有的功能吧。由于现在每个状态对应的处理已经封装到对应的状态类中了，要修改已有的某个状态的功能，直接扩展某个类进行修改就可以了，对其他的程序没有影响。比如，现在要修改正常投票状态对应的功能，对正常投票的用户给予积分奖励，那么只需要扩展正常投票状态对应的类，然后进行修改即可。示例代码如下：

一切良好，对吧，可是怎么让VoteManager使用这个新的实现类呢？按照目前的实现，没有办法，只好去修改VoteManager的vote（）方法中对状态的维护代码了，把使用NormalVoteState的地方换成使用NormalVoteState2。

再看看如何添加新的功能，比如投票超过8次但不足10次的，给个机会，只是禁止登录和使用系统3天，如果再犯，才进入黑名单。要实现这个功能，先要对原来的投票超过8次进入黑名单的功能进行修改，修改成投票超过10次才进入黑名单；然后新加入一个功能，实现超过8次但不足10次的，只是禁止登录和使用系统3天的功能。把这个新功能实现出来。示例代码如下：

实现好了这个类，该怎样加入到已有的系统呢？

同样需要去修改上下文的vote（）方法中对于状态判断和维护的代码，示例代码如下：

好像也实现了功能，而且改动起来确实也变得简单点了，但是仔细想想，是不是没有完全遵循OCP原则？结论是很显然的，明显没有完全遵循OCP原则。

延伸

这里要说明一点，设计原则是大家在设计和开发中尽量去遵守的，但不是一定要遵守，尤其是完全遵守。在实际开发中，完全遵守那些设计原则几乎是不可能完成的任务。

就像状态模式的实际实现中，由于状态的维护和转换在状态模式结构里面，不管你是扩展了状态实现类，还是新添加了状态实现类，都需要修改状态维护和转换的地方，以使用新的实现。

虽然可以有好几个地方来维护状态的变化（这个后面会讲到），但都是在状态模式结构里面的，所以都有这个问题，算是不完美的OCP体验吧。

5．创建和销毁状态对象

在应用状态模式的时候，有一个常见的考虑，那就是：究竟何时创建和销毁状态对象？常见的有以下几个选择。

■　当需要使用状态对象的时候创建，使用完后就销毁它们。

■　提前创建它们并且始终不销毁。

■　采用延迟加载和缓存合用的方式，就是当第一次需要使用状态对象的时候创建，使用完后并不销毁对象，而是把这个对象缓存起来，等待下一次使用，而且在合适的时候，会由缓存框架销毁状态对象。

怎么选择呢？下面给出选择建议。

如果要进入的状态在运行时是不可知的，而且上下文是比较稳定的，不会经常改变状态，而且使用也不频繁，这个时候建议选择第一种方案。

如果状态改变很频繁，也就是需要频繁地创建状态对象，而且状态对象还存储着大量的数据信息，这种情况建议选择第二种方案。

如果无法确定状态改变是否频繁，而且有些状态对象的状态数据量大，有些比较小，一切都是未知的，建议选择第三种方案。

事实上，在实际工程开发过程中，第三种方案是首选。因为它兼顾了前面两种方案的优点，而又避免了它们的缺点，几乎能适应各种情况的需要。只是这个方案在实现的时候，需要实现一个合理的缓存框架，而且要考虑多线程并发的问题，因为需要由缓存框架来在合适的时候销毁状态对象，因此实现上难度稍大。另外在实现中还可以考虑结合享元模式，通过享元模式来共享状态对象。

6．状态模式的调用顺序示意图

状态模式在实现上，对于状态的维护有不同的实现方式。前面的示例中，采用的是在Context中进行状态的维护和转换。这里先画出这种方式的调用顺序示意图，其他的方式则在后面讲到时再画。

在Context中进行状态维护和转换的调用顺序如图18.5所示。

图18.5　在Context中进行状态维护和转换的调用顺序示意图

18.3.2　状态的维护和转换控制

所谓状态的维护，指的是维护状态的数据，给状态设置不同的状态值；而状态的转换，指的是根据状态的变化来选择不同的状态处理对象。在状态模式中，通常有两个地方可以进行状态的维护和转换控制。

一个就是在上下文中。因为状态本身通常被实现为上下文对象的状态，因此可以在上下文中进行状态维护，当然也就可以控制状态的转换了。前面投票的示例就是采用这种方式。

另外一个地方就是在状态的处理类中。当每个状态处理对象处理完自身状态所对应的功能后，可以根据需要指定后继状态，以便让应用能正确处理后续的请求。

先看看示例。为了对比学习，下面来看看如何把前面投票的例子修改成：在状态处理类中进行后续状态的维护和转换。

（1）同样先来看投票状态的接口。没有什么变化。示例代码如下：

（2）对于各个具体的状态实现对象，主要的变化在于：在处理完自己状态对应的功能后，还需要维护和转换状态对象。

一个一个来看吧，先看看正常投票的状态处理对象。示例代码如下：

再来看看重复投票状态对应的处理对象。示例代码如下：

接下来看看恶意投票状态对应的处理对象。示例代码如下：

下面来看看黑名单状态对应的处理对象。没什么变化。示例代码如下：

（3）下面来看看现在的投票管理类该如何实现了？和在上下文中维护和转换状态相比，大致有如下的变化。

■　需要按照每个用户来记录他们对应的投票状态，不同的用户，对应的投票状态是不同的，因此使用一个Map来记录，而不再是原来的一个单一的投票状态对象。

提示

可能有些朋友会问，那为什么前面的实现可以呢？那是因为投票状态是由投票管理对象集中控制的，不同的人员在进入投票方法的时候，是重新判断该人员具体的状态对象的，而现在是要把状态维护分散到各个状态类中，因此需要记录各个状态类判断以后的结果。

■　需要把记录投票状态的数据，还有记录投票次数的数据，提供相应的getter方法，各个状态在处理的时候需要通过这些方法来访问数据。

■　将原来在vote（）方法中进行的状态控制和转换删除，变成直接根据人员来从状态记录的Map中获取对应的状态对象了。

看看实现代码吧。示例代码如下：

（4）实现的差不多了，该来测试了，客户端没有变化，去运行一下，看看效果。看看两种维护状态变化的方式实现的结果一样吗？答案应该是一样的。

那么到底如何选择这两种方式呢？

■　如果状态转换的规则是一定的，一般不需要进行什么扩展规则，那么就适合在上下文中统一进行状态的维护。

■　如果状态的转换取决于前一个状态动态处理的结果，或者是依赖于外部数据，为了增强灵活性，这种情况下，一般是在状态处理类中进行状态的维护。

（5）采用让状态对象来维护和转换状态的调用顺序如图18.6所示。

图18.6　状态对象来维护和转换状态的调用顺序示意图

（6）再来看看这种实现方式下，如何修改已有的功能，或者是添加新的状态处理。

要修改已有的功能，同样是找到对应的状态处理对象，要么直接修改，要么扩展。前面已经示例过了，这里不再赘述。

对于添加新的状态处理的功能，这种实现方式会比较简单。先直接添加新的状态处理的类，然后找到需要转换到这个新状态的状态处理类，修改那个处理类，让其转换到这个新状态就可以了。

比如还是来实现：投票超过8次但不足10次的，给个机会，只是禁止登录和使用系统3天，如果再犯，才进入黑名单的功能。按照现在的方式，示例代码如下：

那么如何加入系统呢？

不再是去修改VoteManger了，而是找到需要转换到这个新状态的那个状态，修改它的状态维护和转换。应该是在恶意投票处理中，让它转换到这个新的状态，也就是把恶意投票处理中的下面这句话：

voteManager.getMapState（）.put（user, new BlackVoteState（））；

替换成：

voteManager.getMapState（）.put（user, new BlackWarnVoteState（））；

这样就自然地把现在新的状态处理添加到了已有的应用中。

18.3.3　使用数据库来维护状态

在实际开发中，还有一个方式来维护状态，那就是使用数据库，在数据库中存储下一个状态的识别数据。也就是说，维护下一个状态演化成了维护下一个状态的识别数据，比如状态编码。

这样，在程序中通过查询数据库中的数据来得到状态编码，然后根据状态编码来创建出相应的状态对象，再委托相应的状态对象进行功能处理。

还是用前面投票的示例来说明，如果使用数据库来维护状态的话，大致如何实现。

（1）首先，就是每个具体的状态处理类中，原本在处理完成后，要判断下一个状态是什么，然后创建下一个状态对象，并设置回到上下文中；但是如果使用数据库的方式，那就不用创建下一个状态对象，也不用设置回到上下文中了，而是把下一个状态对应的编码记入数据库中，这样就可以了。

还是示意一个，看看重复投票状态下的实现吧。示例代码如下：

这里只是示意一下，并不真的去写和数据库操作相关的代码。其他的状态实现类，也做同样类似的修改，这里不再赘述。

（2）在Context中，也就是投票管理对象中，则不需要那个记录所有用户状态的Map了，直接从数据库中获取该用户当前对应的状态编码，然后根据状态编码来创建出状态对象来。原有的示例代码如下：

现在被修改了。示例代码如下：

可能有些朋友会发现，如果向数据库中存储下一个状态对象的状态编码，那么上下文中就不需要再持有状态对象了，相当于把这个功能放到数据库中了。有那么点相似性，不过要注意，数据库存储的只是状态编码，而不是状态对象，获取到数据库中的状态编码后，在程序中仍然需要根据状态编码去真正创建对应的状态对象。

当然，要想程序更通用一点，可以通过配置文件来配置状态编码和对应的状态处理类，也可以直接在数据库中记录状态编码和对应的状态处理类。这样的话，在上下文中，先获取下一个状态的状态编码，然后根据这个状态编码去获取对应的类，再通过反射来创建对象，如此实现就避免了那一长串的if-else，而且以后添加新的状态编码和状态处理对象也不用再修改代码了。示例代码如下：

（3）直接把“转移”记录到数据库中。

还有一种情况是直接把“转移”记录到数据库中，这样会更灵活。所谓转移，指的就是描述从A状态到B状态的转换变化。

比如，在正常投票状态处理对象中指定使用“转移A”，而“转移A”描述的就是从正常投票状态转换成重复投票状态。这样一来，假如今后想要让正常投票处理以后变换成恶意投票状态，就不需要修改程序，而是直接修改数据库中的数据，把数据库中“转移A”的描述数据修改一下，使其描述从正常投票状态转换成恶意投票状态就可以了。

18.3.4　模拟工作流

做企业应用的朋友，大多数都接触过工作流，至少也处理过业务流程。对于工作流，复杂的应用可能会使用工作流中间件，用工作流引擎来负责流程处理，这个会比较复杂。其实工作流引擎的实现也可以应用状态模式，这里不去讨论。

简单点的，把流程数据存放在数据库中，然后在程序中自己来进行流程控制。对于简单的业务流程控制，可以使用状态模式来辅助进行流程控制，因为大部分这种流程都是状态驱动的。

举个例子来说明吧。比如最常见的“请假流程”，流程是这样的：当某人提出请假申请，先由项目经理审批，如果项目经理不同意，审批就直接结束；如果项目经理同意了，再看请假的天数是否超过3天，项目经理的审批权限只有3天以内，如果请假天数在3天以内，那么审批也直接结束，否则就提交给部门经理；部门经理审核过后，无论是否同意，审批都直接结束。流程图如图18.7所示。

图18.7　简单的请假流程示意图

在实际开发中，如果不考虑使用工作流软件，按照流程来自己实现的话，这个流程基本的运行过程简单描述如下。

（1）UI操作：请假人填写请假单，提出请假申请。

（2）后台处理：保存请假单数据到数据库中，然后为项目经理创建一个工作，把工作信息保存到数据库中。

（3）UI操作：项目经理登录系统，获取自己的工作列表。

（4）后台处理：从数据库中获取相应的工作列表。

（5）UI操作：项目经理完成审核工作，提交保存。

（6）后台处理：处理项目经理审核的业务，保存审核的信息到数据库。同时判断后续的工作，如果是需要人员参与的，就为参与下一个工作的人员创建工作，把工作信息保存到数据库中。

（7）UI操作：部门经理登录系统，获取自己的工作列表，基本上是重复第3步。

（8）后台处理：从数据库中获取相应的工作列表，基本上是重复第4步。

（9）UI操作：部门经理完成审核工作，提交保存，基本上是重复第5步。

（10）后台处理：类推，基本上是重复第6步。

1．实现思路

仔细分析上面的流程图和运行过程，把请假单在流程中的各个阶段的状态分析出来，会发现，整个流程完全可以看成是状态驱动的。

在上面的流程中，请假单大致有如下状态：等待项目经理审核、等待部门经理审核、审核结束。如果用状态驱动来描述上述流程：

（1）当请假人填写请假单，提出请假申请后，请假单的状态是等待项目经理审核状态。

（2）当项目经理完成审核工作，提交保存后，如果项目经理不同意，请假单的状态是审核结束状态；如果项目经理同意，请假天数又在3天以内，请假单的状态是审核结束状态；如果项目经理同意，请假天数大于3天，请假单的状态是等待部门经理审核状态。

（3）当部门经理完成审核工作，提交保存后，无论是否同意，请假单的状态都是审核结束状态。

既然可以把流程看成是状态驱动的，那么就可以自然地使用状态模式，每次当相应的工作人员完成工作，请求流程响应的时候，流程处理的对象会根据当前所处的状态，把流程处理委托给相应的状态对象去处理。

还考虑到在一个系统中会有很多流程，虽然不像通用工作流那么复杂的设计，但还是稍稍提炼一下，至少把各个不同的业务流程，在应用状态模式时的公共功能，或者是架子给搭出来，以便复用这些功能。

（1）这个公共的状态处理机首先提供一个公共的状态处理机。

相当于一个公共的状态模式的Context，在其中提供基本的、公共的功能。这样在实现具体的流程的时候，可以简单一些，对于要求不复杂的流程，甚至可以直接使用。示例代码如下：

（2）来提供公共的状态接口。各个状态对象在处理流程的时候，可以使用统一的接口，可是它们需要的业务数据从何而来呢？那就通过上下文传递过来。示例代码如下：

好了，现在架子已经搭出来了，在实现具体的流程的时候，可以分别扩展它们，来加入跟具体流程相关的功能。

2．使用状态模式来实现流程

（1）定义请假单的业务数据模型。示例代码如下：

（2）定义处理客户端请求的上下文。虽然这里并不需要扩展功能，但还是继承一下状态机，表示可以添加自己的处理。示例代码如下：

（3）下面来定义处理请假流程的状态接口。虽然这里并不需要扩展功能，但还是继承一下状态，表示可以添加自己的处理。示例代码如下：

（4）下面该来实现各个状态具体的处理对象了。

先看看处理项目经理审核的状态类的实现。示例代码如下：

接下来看看处理部门经理审核的状态类的实现，示例代码如下：

再来看看处理审核结束的状态类的实现。示例代码如下：

（5）由于上面的实现中，涉及大量需要数据库支持的功能，同时还需要提供页面来让用户操作，才能驱动流程运行，所以无法像其他示例那样，写个客户端就能进行测试。当然这个可以在后面稍稍改变，模拟一下实现，就可以运行来看效果了。

先来看看此时用状态模式实现的这个流程的程序结构示意图，如图18.8所示。

图18.8　用状态模式实现流程的程序结构示意图

下面来看看怎么改造上面的示例，让它能运转起来。这样更加有利于大家来体会在处理这种流程的应用中，如何使用状态模式。

3．改进上面使用状态模式实现流程的示例

上面的示例不能运行有两个基本原因：一是没有数据库实现部分，二是没有界面。要解决这个问题，那就采用字符界面，来让客户输入数据；另外把运行放到同一个线程中，这样就不存在传递数据的问题，也就不需要保存数据了，因为数据在内存中。

原来是提交了请假申请，把数据保存在数据库中，然后项目经理从数据库中获取这些数据。现在一步到位，直接把申请数据传递过去，就可以处理了。

（1）根据上面的思路，其实也就是来修改那几个状态处理对象的实现。

先看看处理项目经理审核的状态类的实现，使用Scanner接受命令行输入数据。示例代码如下：

接下来看看处理部门经理审核的状态类的实现。示例代码如下：

再来看看处理审核结束的状态类的实现。示例代码如下：

（2）万事俱备，可以写个客户端，来开始我们的流程之旅了。示例代码如下：

辛苦了这么久，一定要好好地运行一下，体会在流程处理中是如何使用状态模式的。

第一步：运行一下，刚开始会出现如下信息：

第二步：程序并没有停止，在等待你输入项目经理审核的结果，如果输入1，表示同意，那么程序会继续判断，发现请假天数5天大于项目经理审核的范围了，会提交给部门经理审核。在控制台输入1，然后回车看看，会出现如下信息：

第三步：同样，程序仍然没有停止，在等待你输入部门经理审核的结果，假如输入1，然后回车，看看会发生什么。提示信息如下：

这个时候流程运行结束了，程序运行也结束了，有点流程控制的意味了吧。

如果上面第一步运行以后，在第二步输入2，也就是项目经理不同意，会怎样呢？应该就不会再到部门经理了吧，试试看。运行提示信息如下：

（3）小结。

事实上，上面的程序可以和数据库结合起来，比如把审核结果存放在数据库中，也可以把审核的步骤也放到数据库中，每次运行的时候从数据库中获取这些值，判断是创建哪一个状态处理类，然后执行相应的处理就可以了。

现在这些东西都在内存中，所以程序不能停止，否则流程就运行不下去了。

另外，为了演示的简洁性，这里做了相应的简化，比如没有去根据申请人选择相应的项目经理和部门经理，也没有去考虑如果申请人就是项目经理或者部门经理怎么办。只是为了让大家看明白状态模式在其中的应用，主要是为了体现状态模式而不是业务。

18.3.5　状态模式的优缺点

状态模式有以下优点。

■　简化应用逻辑控制

状态模式使用单独的类来封装一个状态的处理。如果把一个大的程序控制分成很多小块，每块定义一个状态来代表，那么就可以把这些逻辑控制的代码分散到很多单独的状态类中去，这样就把着眼点从执行状态提高到整个对象的状态，使得代码结构化和意图更清晰，从而简化应用的逻辑控制。

对于依赖于状态的if-else，理论上来讲，也可以改变成应用状态模式来实现，把每个if或else块定义一个状态来代表，那么就可以把块内的功能代码移动到状态处理类中，从而减少if-else，避免出现巨大的条件语句。

■　更好地分离状态和行为

状态模式通过设置所有状态类的公共接口，把状态和状态对应的行为分离开，把所有与一个特定的状态相关的行为都放入一个对象中，使得应用程序在控制的时候，只需要关心状态的切换，而不用关心这个状态对应的真正处理。

■　更好的扩展性

引入了状态处理的公共接口后，使得扩展新的状态变得非常容易，只需要新增加一个实现状态处理的公共接口的实现类，然后在进行状态维护的地方，设置状态变化到这个新的状态即可。

■　显式化进行状态转换

状态模式为不同的状态引入独立的对象，使得状态的转换变得更加明确。而且状态对象可以保证上下文不会发生内部状态不一致的情况，因为上下文中只有一个变量来记录状态对象，只要为这一个变量赋值就可以了。

状态模式也有一个很明显的缺点，一个状态对应一个状态处理类，会使得程序引入太多的状态类，这样程序变得杂乱。

18.3.6　思考状态模式

1．状态模式的本质

　　　状态模式的本质：根据状态来分离和选择行为。

仔细分析状态模式的结构，如果没有上下文，那么就退化回到只有接口和实现了，正是通过接口，把状态和状态对应的行为分开，才使得通过状态模式设计的程序易于扩展和维护。

而上下文主要负责的是公共的状态驱动，每当状态发生改变的时候，通常都是回调上下文来执行状态对应的功能。当然，上下文自身也可以维护状态的变化，另外，上下文通常还会作为多个状态处理类之间的数据载体，在多个状态处理类之间传递数据。

2．何时选用状态模式

建议在以下情况中选用状态模式。

■　如果一个对象的行为取决于它的状态，而且它必须在运行时刻根据状态来改变它的行为，可以使用状态模式，来把状态和行为分离开。虽然分离开了，但状态和行为是有对应关系的，可以在运行期间，通过改变状态，就能够调用到该状态对应的状态处理对象上去，从而改变对象的行为。

■　如果一个操作中含有庞大的多分支语句，而且这些分支依赖于该对象的状态，可以使用状态模式，把各个分支的处理分散包装到单独的对象处理类中，这样，这些分支对应的对象就可以不依赖于其他对象而独立变化了。

18.3.7　相关模式

■　状态模式和策略模式

这是两个结构相同，功能各异的模式，具体的在策略模式里面讲过了，这里就不再赘述。

■　状态模式和观察者模式

这两个模式乍一看，功能是很相似的，但是又有区别，可以组合使用。

这两个模式都是在状态发生改变的时候触发行为，只不过观察者模式的行为是固定的，那就是通知所有的观察者；而状态模式是根据状态来选择不同的处理。

从表面来看，两个模式功能相似，观察者模式中的被观察对象就好比状态模式中的上下文，观察者模式中当被观察对象的状态发生改变的时候，触发的通知所有观察者的方法就好比是状态模式中，根据状态的变化选择对应的状态处理。

但实际这两个模式是不同的，观察者模式的目的是在被观察者的状态发生改变的时候，触发观察者联动，具体如何处理观察者模式不管；而状态模式的主要目的在于根据状态来分离和选择行为，当状态发生改变的时候，动态地改变行为。

这两个模式是可以组合使用的，比如在观察者模式的观察者部分，当被观察对象的状态发生了改变，触发通知了所有的观察者以后，观察者该怎么处理呢？这个时候就可以使用状态模式，根据通知过来的状态选择相应的处理。

■　状态模式和单例模式

这两个模式可以组合使用，可以把状态模式中的状态处理类实现成单例。

状态模式和享元模式

这两个模式可以组合使用。

由于状态模式把状态对应的行为分散到多个状态对象中，会造成很多细粒度的状态对象，可以把这些状态处理对象通过享元模式来共享，从而节省资源。