State模式.doc

State模式 State模式的设计目标：使得对象按照其状态决定其应该执行的操作，也就是对同一个对象而言，对应不同的状态可以有不同的行为。 图 1 state模式的类图模型 State模式的类图完整模型可以用图1来表示。doRequest()方法调用targetState.handleRequest()方法，于是doRequest()的调用通过虚函数属性转换为特定版本的handleRequest()，handleRequest()的版本根据目标的状态而做出何时的改变，客户不需要知道目标的状态。 虽然State模式不处理一旦执行后的handleRequest()后将怎样建立持续状态的问题。它并不需要处理转换函数（因为面向对象的机制可以制动做到这一点），但是将其作为框架来实现转换函数是很有用的。 State模式在实际使用中比较多，适合“状态的切换”。因为我们经常会使用if--else进行一个对象状态判断，然后执行不同的操作，如果针对状态的这样判断切换反复出现，我们就可以考虑使用State模式来避免写一大堆条件语句。 State模式实现的一个动态这些一个整体一个状态变化图。一般来说，使用该模式的状态之间存在着一种线性变化的关系，也就是一个状态变为另一个。客户代码并不清楚这些状态在何时发生变化，这样做的好处是在组成整个变化过程中某些状态之间需要插入一个新的状态，或者状态的顺序之间发生变化，对客户是不可见。实现模式一方面，修改的也只是相的状态。在处于不同的状态时，客户代码执行的方法也是不同的。 图 2 操作系统将一个进程加入等待队列的类图 应用二：津贴发放系统中的State模式 假设每个员工发放津贴的额度一般根据职工的工龄长短来确定，随着工龄的增长，津贴的基数将相应上涨，即津贴额度也将有所变化。 因此，对不同的员工发放津贴因其工龄的不同而不同；对同一个职工因其为企业服务的时间长短而得到的津贴也不同。所以在发放津贴是对每个不同状态的员工发放的津贴是不同的；这中设想也正符合State模式对一个对象不同状态执行不同操作。 如果将企业的职工按工龄分为三种：intern，junior，senior，retired；那么对一个职工发放津贴时需要考虑四种情况。但是如果采用State设计模式对财务系统的实现人员来说根部不用考虑这些情况。 下图是本设想的State模式的一个实现类图。 图 3