深入讨论设计模式中的State状态模式

最近看了些部门牛人的代码，有网络框架也有具体的业务系统，其中频繁使用了State的设计模式。在实现大规模复杂逻辑时，状态设计模式确实是非常有效的手段。

为什么使用状态模式

在一个复杂的逻辑中，一个对象的行为往往是不连续的，这种不连续是指站在代码执行的角度来看的：对象的一个完整操作可能会被多个异步操作所中断，而高性能的后台服务器是不可能阻塞在单个对象的某个操作上，这时候就需要保存对象的临时状态，等待异步操作结束后才重新继续之前中断的操作。

当对象的类型和操作都快速增加时，代码的逻辑可能会变得非常复杂，并且难以维护。此时把对象的状态接口进行抽象，将不同状态和行为以类为单位进行封装就可以很好的维护逻辑的清晰性，保证代码的可维护性。

状态模式的实质

在一个复杂的逻辑中，对象的状态改变需要大量依赖外部的消息或者环境信息，而且状态改变本身的实现是琐碎或复杂的。

状态设计模式使用的场景

状态模式的使用场景比较通用，只要涉及较为复杂的逻辑和事件驱动的情景下，都可以使用状态模式。例如在一个TCP连接中，包括这个open，listen，connected，closed等若干状态，各个状态之间的转换多而复杂，是比较典型的适用状态模式的场景。使用状态模式可以封装这个状态的变化规则，从而对逻辑进行较好的抽象，不必涉及到状态的使用者。同样状态设计模式在工作流或游戏等各种系统中也有大量使用，甚至是这些系统的核心功能设计。

几个例子

说了这么多，都是从概念上的解释，那么下面看一些例子：

在驴哥实现的一个系统中，需要实现对于不同事务的管理（这里只列举了add和del的操作），每一个事务有较为复杂的业务逻辑（实际的实现要复杂很多，这里只进行了简单的抽象）。通过状态模式，每次对于事务的操作只需要通过调用统一Process操作即可，而一个单独的操作（比如add）中不同State之间的转换则在具体的HandleStat*系列函数中实现。因为系统存在不同的操作（add和del），所以对不同操作抽象出基类，这样以后扩充新的操作也非常简单，而且不影响现有架构。



下面是在另一种状态模式的实现，这种模式严格按照了经典“四人帮”的《设计模式》书籍中对State模式的说明来实现的。不同点在于对于状态的抽象更加彻底，实现各种状态的继承结构，而且状态改变的逻辑也和状态本身耦合在了一起。这一种实现是比较纯粹的状态机模式，上面的实现有点结合了命令模式的感觉。总之各有自身的优点吧。



设计模式的核心更多在于概念上的抽象，在于方法论，具体的实现细节比较灵活。以上我最近的一些心得，欢迎感兴趣的同学相互讨论，共同进步。