天天看点

介绍Java 状态设计模式

介绍Java 状态设计模式

本文我们介绍GoF中一个行为设计模式————状态模式。首先总体介绍其目的,解释其能解决什么问题。然后看下状态模式的UML图并通过实际示例进行实现。

概要说明

状态设计模式的主要目的是在不改变类的情况下改变对象的行为。同时,实现该模式代码需保持简洁,不能有很多if/else语句。

加入我们有一个包裹需要邮寄。包裹本身可以被订购,然后送到邮局,最后由客户接收。现在需要根据实际状态打印投递过程的状态。

最简单的方法增加一些布尔标志,然后在类的每个方法中使用简单if/else语句。在这个简单场景中不会很复杂,然而当有更多状态需要处理时可能会变得复杂并污染代码。

另外,每个状态的业务逻辑将分散在不同方法中。这时可以考虑使用状态模式进行优化。通过使用状态模式,我们在决策类中封装逻辑,符合单一责任原则和开闭原则,让代码更简洁、更易维护。

UML 图

介绍Java 状态设计模式

在uml图中,我们看到Context类与程序执行过程中将被改变的State进行关联。

上下文委托行为给状态实现。也就是说,所有传入的请求都将由状态的具体实现来处理。我们看到状态和逻辑是分离的,添加新状态很简单——仅根据需要添加另一个状态实现。

代码实现

下面开始设计应用。前面提及包裹有预定、投递和已收状态。因此,我们有三个状态和上下文类。

首先,我们定义context类,也就是我们的Package类:

public class Package {
 
    private PackageState state = new OrderedState();
 
    // getter, setter
 
    public void previousState() {
        state.prev(this);
    }
 
    public void nextState() {
        state.next(this);
    }
 
    public void printStatus() {
        state.printStatus();
    }
}
           

我们看到包含一个状态的引用,同时 previousState(), nextState() 和 printStatus() 三个方法委托工作给状态对象。状态被彼此链接,每个状态在两个方法中将基于传入状态对象被设置为另一种状态。

客户端与Package类进行交互,无需处理并设置状态,所有的客户端仅需要做的是调用两个方法进行前进或后退。接下来我们实现PackageState接口和其三个实现:

public interface PackageState {
 
    void next(Package pkg);
    void prev(Package pkg);
    void printStatus();
}
           

该接口需被每个具体状态类进行实现。首先我们实现OrderState:

public class OrderedState implements PackageState {
 
    @Override
    public void next(Package pkg) {
        pkg.setState(new DeliveredState());
    }
 
    @Override
    public void prev(Package pkg) {
        System.out.println("The package is in its root state.");
    }
 
    @Override
    public void printStatus() {
        System.out.println("Package ordered, not delivered to the office yet.");
    }
}
           

当包裹被预定后,next方法改变其状态为下一个状态。预定状态被显示标记为初始状态,我们看到两个方法如何改变状态。

下面看DeliveredState 类:

public class DeliveredState implements PackageState {
 
    @Override
    public void next(Package pkg) {
        pkg.setState(new ReceivedState());
    }
 
    @Override
    public void prev(Package pkg) {
        pkg.setState(new OrderedState());
    }
 
    @Override
    public void printStatus() {
        System.out.println("Package delivered to post office, not received yet.");
    }
}
           

我们有看到了状态之间的链接。包裹状态从预定状态在不断变化,printStatus方法保持同样变化。

最后是ReceivedState类:

public class ReceivedState implements PackageState {
 
    @Override
    public void next(Package pkg) {
        System.out.println("This package is already received by a client.");
    }
 
    @Override
    public void prev(Package pkg) {
        pkg.setState(new DeliveredState());
    }
}
           

因为已经是最后状态,仅能回滚至前一个状态。

我们已经看到了这样设计的好处,因为一个状态知道另一个状态,它们彼此紧密关联。

测试

下面通过测试看看如何实现流转。首先让我们验证一下状态转换是否如预期一样:

@Test
public void givenNewPackage_whenPackageReceived_thenStateReceived() {
    Package pkg = new Package();
 
    assertThat(pkg.getState(), instanceOf(OrderedState.class));
    pkg.nextState();
 
    assertThat(pkg.getState(), instanceOf(DeliveredState.class));
    pkg.nextState();
 
    assertThat(pkg.getState(), instanceOf(ReceivedState.class));
}
           

然后,我们检查下包裹状态是否可以回滚:

@Test
public void givenDeliveredPackage_whenPrevState_thenStateOrdered() {
    Package pkg = new Package();
    pkg.setState(new DeliveredState());
    pkg.previousState();
 
    assertThat(pkg.getState(), instanceOf(OrderedState.class));
}
           

下面验证状态改变时, printStatus() 方法输出结果是否正确:

public class StateDemo {
 
    public static void main(String[] args) {
 
        Package pkg = new Package();
        pkg.printStatus();
 
        pkg.nextState();
        pkg.printStatus();
 
        pkg.nextState();
        pkg.printStatus();
 
        pkg.nextState();
        pkg.printStatus();
    }
}
           

输出结果如下:

Package ordered, not delivered to the office yet.
Package delivered to post office, not received yet.
Package was received by client.
This package is already received by a client.
Package was received by client.
           

当我们一直在改变上下文的状态时,行为在改变,但是类保持不变,使用的API也一样。

而且,状态之间的转换已经发生,我们类改变了状态并因此改变了其行为。

缺点

状态模式的缺点是需要实现状态转换。这导致状态硬编码,一般情况不是好的习惯。但这取决于你的需求,可能也不是问题。

状态 VS 策略

两个模式比较类似,但UML图相同,其背后思想却有差异。

首先,策略模式定义了一组可互换的算法。通常它们实现相同目的,但有不同实现。如排序或渲染算法。状态模式中行为可能根据实际状态而完全改变。

其次,策略模式中客户端必须知道可以显式使用和更改的策略。而状态模式中每个状态链接到另一个状态,就像在有限状态机中自动流转。

总结

状态设计模式在避免过多使用if/else语句是非常有用。其把业务逻辑抽取至独立类中,上下文对象代理状态类的方法行为。此外,我们可以利用状态之间的转换从而更改上下文的状态。

通常该设计模式在简单应用中使用较好,更好的方法可以看下Spring State Machine。

继续阅读