设计模式教程：状态模式（State Pattern）
一、概述
状态模式（State Pattern）是一种行为型设计模式，允许对象在内部状态发生变化时改变其行为。换句话说，状态模式让对象的行为随其状态变化而变化。它的主要目的是将状态相关的行为封装到状态类中，从而避免在类中大量使用 if-else 或 switch 语句来判断不同的状态并执行相应的操作。
二、状态模式的结构
状态模式的核心概念在于将不同的状态抽象出来，并且将每个状态的行为封装到独立的类中。它的结构包括以下几个部分：
1. Context（上下文类）
- 作用：维护当前的状态对象，并提供接口来切换不同的状态。
- 职责：在不同的状态间切换，并委托请求给当前状态类来执行具体的行为。
2. State（状态接口/抽象类）
- 作用：定义一个状态接口或抽象类，所有的具体状态都需要实现这个接口或继承这个抽象类。
- 职责：声明一个或多个方法，用来处理当前状态下的行为。
3. ConcreteState（具体状态类）
- 作用：每个具体的状态类都实现状态接口，并封装与该状态相关的行为。
- 职责：为每个状态提供具体的行为。
三、状态模式的优缺点
优点：
- 减少条件判断：状态模式将每个状态的行为提取到独立的状态类中，避免了复杂的
if-else或switch-case判断，代码更加清晰。 - 增加可维护性：状态变化不再依赖于复杂的条件判断，修改时只需修改对应的状态类，符合开闭原则（对扩展开放，对修改关闭）。
- 易于扩展：可以灵活地添加新的状态类，而无需修改原有代码，增强了系统的可扩展性。
缺点：
- 类的数量增加：每个状态需要一个独立的类，这会增加代码中的类的数量，尤其是在状态较多时，可能导致类数量较为庞大。
- 理解复杂性增加：相较于简单的条件判断，状态模式需要开发者理解更多的设计模式概念和类的交互，学习成本较高。
四、状态模式的应用场景
状态模式非常适合以下场景：
- 对象的行为依赖于状态：当一个对象的行为会随着状态的变化而变化时，状态模式可以帮助更好地组织和管理这些状态。
- 避免复杂的条件语句：当对象的行为由多个状态决定，并且需要通过
if-else或switch-case来判断时，状态模式可以帮助拆分条件逻辑，提升代码的可维护性。 - 状态之间有复杂的转换规则：如果状态之间的转换较为复杂（例如需要验证某些条件），状态模式可以将这些转换封装到各自的状态类中，简化代码。
五、状态模式的实现
为了更好地理解状态模式，下面通过一个电灯开关的例子来展示如何实现。
1. 定义状态接口
首先，我们需要定义一个状态接口 State，它声明了 handleRequest 方法，所有具体状态类都需要实现这个方法。
public interface State {
void handleRequest();
}
2. 定义具体状态类
接下来，我们定义两个具体的状态类，分别表示电灯的开和关。
// 具体状态类：电灯开启
public class OnState implements State {
@Override
public void handleRequest() {
System.out.println("电灯已经打开");
}
}
// 具体状态类：电灯关闭
public class OffState implements State {
@Override
public void handleRequest() {
System.out.println("电灯已经关闭");
}
}
3. 定义上下文类（Context）
Light 类是电灯的上下文类，它持有当前的状态，并能够在不同的状态之间切换。它委托状态的具体行为给当前状态类的 handleRequest() 方法。
public class Light {
private State state;
// 默认电灯状态为关闭
public Light() {
this.state = new OffState();
}
// 设置当前状态
public void setState(State state) {
this.state = state;
}
// 请求当前状态执行任务
public void request() {
state.handleRequest();
}
}
4. 使用状态模式
最后，我们在 Main 方法中创建一个 Light 对象，模拟电灯的开关状态变化。
public class Main {
public static void main(String[] args) {
Light light = new Light();
// 初始状态：电灯关闭
light.request(); // 输出：电灯已经关闭
// 切换到开状态
light.setState(new OnState());
light.request(); // 输出：电灯已经打开
// 切换回关闭状态
light.setState(new OffState());
light.request(); // 输出：电灯已经关闭
}
}
六、深入分析
在这个例子中，Light 类作为上下文类（Context）保存了当前的状态，并委托状态类来执行具体的操作。通过 setState() 方法，可以动态地切换不同的状态，而不需要在 Light 类中使用 if-else 或 switch 语句来判断当前状态。每个具体状态类（OnState 和 OffState）实现了 State 接口，并且提供了状态相关的具体行为。
这个设计的好处在于：
- 当需要新增其他状态（如电灯的“闪烁”状态），只需要添加一个新的状态类，而不需要修改
Light类。 - 状态类中封装了具体的行为，
Light类只负责状态的切换和委托任务，符合单一职责原则。
七、状态模式与其他设计模式的比较
1. 状态模式 vs 策略模式
状态模式和策略模式都涉及到将行为封装到独立的类中，但它们的应用场景不同：
-
状态模式：侧重于对象的状态发生变化时，行为也随之变化。状态模式的状态之间是互相依赖的，不同状态之间通常有特定的转换规则。
-
策略模式：侧重于选择不同的算法或策略，不同策略之间通常是独立的，可以互换。
简而言之，状态模式关注的是 状态变化驱动行为变化，而策略模式关注的是 算法选择。
2. 状态模式 vs 观察者模式
-
状态模式：通过将行为与状态分离，使得不同状态下的行为独立于对象本身。
-
观察者模式：一种发布-订阅模式，主要用于事件通知和监听，而不是在状态变化时改变对象行为。
八、总结
状态模式是一个非常有效的设计模式，它能够将复杂的条件判断拆分到不同的状态类中，使得代码更加清晰、易于维护和扩展。它特别适用于那些行为随状态变化而变化的对象。在实际开发中，状态模式可以大大简化系统的设计，提高代码的灵活性和可维护性。虽然会增加类的数量，但在状态较为复杂或变化频繁的场景下，状态模式是一个非常值得采用的解决方案。
版权声明
- 本文内容属于原创，欢迎转载，但请务必注明出处和作者，尊重原创版权。
- 转载时，请附带原文链接并注明“本文作者：扣丁梦想家
- 禁止未经授权的商业转载。
如果您有任何问题或建议，欢迎留言讨论。