switch (state) {
// 处理状态Opened的分支
case (Opened): {
// 执行动作Open
open();
// 检查是否有激发状态转换的事件产生
if (checkStateChange()) {
// 对状态机的状态进行转换
performStateChange();
}
break;
}
// 处理状态Closed的分支
case (Closed): {
// 执行动作Close
close();
// 检查是否有激发状态转换的事件产生
if (checkStateChange()) {
// 对状态机的状态进行转换
performStateChange();
}
break;
}
// 处理状态Locked的分支
case (Locked): {
// 执行动作Lock
lock();
// 检查是否有激发状态转换的事件产生
if (checkStateChange()) {
// 对状态机的状态进行转换
performStateChange();
}
break;
}
// 处理状态Unlocked的分支
case (Unlocked): {
// 执行动作Lock
unlock();
// 检查是否有激发状态转换的事件产生
if (checkStateChange()) {
// 对状态机的状态进行转换
performStateChange();
}
break;
}
}
但checkStateChange()和performStateChange()这两个函数本身依然会在面对很复杂的状态机时,内部逻辑变得异常臃肿,
甚至可能是难以实现。
在很长一段时期内,使用switch语句一直是实现有限状态机的唯一方法,甚至像编译器这样复杂的软件系统,大部分也都直接
采用这种实现方式。但之后随着状态机应用的逐渐深入,构造出来的状态机越来越复杂,这种方法也开始面临各种严峻的考
验,其中最令人头痛的是如果状态机中的状态非常多,或者状态之间的转换关系异常复杂,那么简单地使用switch语句构造出
来的状态机将是不可维护的。
三、自动生成状态机三、自动生成状态机
为实用的软件系统编写状态机并不是一件十分轻松的事情,特别是当状态机本身比较复杂的时候尤其如此,许多有过类似经历
的程序员往往将其形容为"毫无创意"的过程,因为他们需要将大量的时间与精力倾注在如何管理好状态机中的各种状态上,而
不是程序本身的运行逻辑。作为一种通用的软件设计模式,各种软件系统的状态机之间肯定会或多或少地存在着一些共性,因
此人们开始尝试开发一些工具来自动生成有限状态机的框架代码,而在Linux下就有一个挺不错的选择──FSME(Finite
State Machine Editor)。
图2 可视化的FSME