介绍Java 状态设计模式
本文我们介绍GoF中一个行为设计模式————状态模式。首先总体介绍其目的，解释其能解决什么问题。然后看下状态模式的UML图并通过实际示例进行实现。
概要说明
状态设计模式的主要目的是在不改变类的情况下改变对象的行为。同时，实现该模式代码需保持简洁，不能有很多if/else语句。
加入我们有一个包裹需要邮寄。包裹本身可以被订购，然后送到邮局，最后由客户接收。现在需要根据实际状态打印投递过程的状态。
最简单的方法增加一些布尔标志，然后在类的每个方法中使用简单if/else语句。在这个简单场景中不会很复杂，然而当有更多状态需要处理时可能会变得复杂并污染代码。
另外，每个状态的业务逻辑将分散在不同方法中。这时可以考虑使用状态模式进行优化。通过使用状态模式，我们在决策类中封装逻辑，符合单一责任原则和开闭原则，让代码更简洁、更易维护。
UML 图
在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。
本文参考链接：https://blog.csdn.net/neweastsun/article/details/90180961
