C++设计模式之状态模式(四)

4、状态模式总结

    状态模式将一个对象在不同状态下的不同行为封装在一个个状态类中，通过设置不同的状态对象能够让环境对象拥有不同的行为。而状态转换的细节对于client而言是透明的。client不直接操作状态类。也就不须要知道状态转换细节。减少了client与详细状态类的耦合性。状态类和环境类是一种组合的关系，当client调用环境类的方法时，环境类将托付调用状态类的方法。

使用状态模式封装了一个个详细的状态类，能够避免出现if...else拥挤情况，使得代码易于维护，也更具扩展性。同一时候封装一个个状态类，也体现了"单一原则"。

在实际开发中。状态模式具有较高的使用频率。

1. 主要长处

    状态模式的主要长处例如以下：

    (1) 封装了状态的转换规则，在状态模式中能够将状态的转换代码封装在环境类或者详细状态类中。能够对状态转换代码进行集中管理，而不是分散在一个个业务方法中，符合"单一原则"。

    (2) 将全部与某个状态有关的行为放到一个类中，仅仅须要注入一个不同的状态对象就可以使环境对象拥有不同的行为。

    (3) 同意状态转换逻辑与状态对象合成一体。而不是提供一个巨大的条件语句块，状态模式能够让我们避免使用庞大的条件语句来将业务方法和状态转换代码交织在一起。

    (4) 能够让多个环境对象共享一个状态对象。从而降低系统中对象的个数。

2. 主要缺点

    状态模式的主要缺点例如以下：

    (1) 状态模式的使用必定会添加系统中类和对象的个数。导致系统执行开销增大。

    (2) 状态模式的结构与实现都较为复杂，假设使用不当将导致程序结构和代码的混乱。添加系统设计的难度。

    (3) 状态模式对“开闭原则”的支持并不太好，添加新的状态类须要改动那些负责状态转换的源码，否则无法转换到新增状态；并且改动某个状态类的行为也需改动相应类的源码。

3.适用场景

    在下面情况下能够考虑使用状态模式：

    (1) 对象的行为依赖于它的状态（如某些属性值）。状态的改变将导致行为的变化。

    (2) 在代码中包括大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差。不能方便地添加和删除状态，而且导致客户类与类库之间的耦合增强。

4.状态模式详细应用

    

    (1)电梯升降系统的设计: 存在打开、关闭、执行、停止状态。

各个状态下将有不同的行为。

比如:在执行状态下能够进行停止操作，但无法进行打开和关闭操作。

    (2)投票系统的设计: 投票1次则为正常投票状态、投票次数在2---5次之间则为反复投票状态、投票次数在5---8次之间则为恶意投票状态、投票次数大于8次则拉入黑名单状态。

     

    (3)酒店订房系统的设计:存在订房状态、入住状态、取消订状态、退房状态。

各状态下相应有不同的行为。

    

    (4)超市、酒店、Ktv存在不同等级的用户，各等级用户处于不同状态，相应有不同权限的行为； 在游戏中也相同存在各种不同角色状态，各状态相应有不同的行为。

     

    (5)银行取款系统的设计:存在正常状态、透支状态、冻结状态。不同状态下将有不同行为。比如:冻结状态不能进行取款，而正常状态和透支状态能够进行取款操作。

    (6)操作系统的任务调度状态图: 存在等待状态、就绪状态、执行状态、停止状态。

    (7)TCP网络连接过程中，存在三次握手状态。

发送连接请求、应答请求、建立连接、断开连接等状态。

    (8)数据库中的事务处理机制。存在OldClean状态、OldDirty状态、OldDelete状态、Deleted状态。

    (9)在工控领域。通信领域存在大量的状态图。某些芯片也存在时序图，高低电平的变化，系统时钟信号的变化，存在大量状态的变化。

    (10)生活中的状态模式: 从儿童到中年，再到老年，是人生状态的变化；从35度骤降到15度是气候的变化。白手起家到腰缠万贯是事业的变化。