本文为敏捷软件开发 - 原则、模式与实践系列的一部分。
本文对应原书第29章
STATE模式
STATE模式既具有switch/case语句的效率又具有解释迁移表的灵活性。
图1上图展示该模式的结构。Turnstile类拥有关于事件的公有方法以及关于动作的受保护方法。它持有一个指向TurnstileState接口的引用。当Turnstile的两个事件方法中的一个被调用时,它就把这个事件委托给Turnstilestate对象。Turnstilestate的方法实现了LOCKED状态下的相应动作。
TurnstileUnlockedState的方法实现了UNLOCKED状态下的相应动作。为了改变FSM的状态,就要把这两个派生类之一的实例赋值给Turnstile对象中的引用。
STATE模式和STRATEGY模式
STATE模式和STRATEGY模式类似,它们都有一个上下文类,都委托给一个具有几个派生类的多态基类。不同之处(见下图)在于,在STATE模式中,派生类持有回指向上下文的引用。派生类的主要功能是使用这个引用选择并调用上下文类中的方法。在STRATEGY模式中,不存在这样的限制以及意图。STRATEGY的派生类不必持有指向上下文类的引用,并且也不需要去调用上下文类的方法。所以,所有的STATE模式实例同样也是STRATEGY模式实例,但是并非所有的STRATEGY模式实例都是STATE模式实例。
图2STATE模式的代价和收益
STATE模式彻底地分离了状态机的逻辑和动作。动作是在Context类中实现的,而逻辑则是分布在State类的派生类中。这就使得二者可以非常容易地独立变化、互不影响。例如,只要使用State类的另一个派生类,就可以非常容易地在一个不同的状态逻辑中重用Context类的动作。此外,我们也可以在不影响State派生类逻辑的情况下创建Context子类来更改或者替换动作实现。
该方法的另外一个好处就是它非常高效。它基本上和嵌套switch/case实现的效率完全一样。因此,该方法既具有表驱动方法的灵活性,又具有嵌套swtich/case方法的效率。
这项技术的代价体现在两个方面。第一,State派生类的编写完全是一项乏味的工作。编写一个具有20个状态的状态机会使人精神麻木。第二,逻辑分散。无法在一个地方就看到整个状态机逻辑。因此,这使得代码难以维护。这会使人想起嵌套switch/case方法的晦涩性。
完整内容请查看敏捷软件开发 - 原则、模式与实践系列
网友评论