状态模式是一种行为型设计模式，它允许一个对象在其内部状态改变时改变它的行为。这个对象看起来像是改变了其类。在软件开发中，当一个对象的内在状态改变时，允许其改变行为，这种设计模式解决了复杂的条件分支判断问题。通过将各种状态的具体行为封装到独立的类中，并将这些行为委托给当前状态对象，我们可以消除庞大的条件分支语句，使得代码结构更加清晰，扩展性更强。
什么是状态模式及其应用场景
状态模式的核心思想是将状态逻辑分散到不同的状态类中，而不是集中在一个庞大的上下文类中。在没有使用状态模式的情况下，我们通常会在方法中编写大量的if-else或switch语句来判断当前状态，并根据不同状态执行不同逻辑。这种做法在状态较少时看似简单，但随着业务发展，状态数量增加，条件分支会呈指数级膨胀，导致代码难以阅读和维护。
这种模式的应用场景非常广泛。最典型的例子是订单处理系统，一个订单通常包含待支付、已支付、发货中、已签收、已取消等多种状态。在不同状态下，订单对同一操作（如取消订单）的响应是完全不同的。在待支付状态下，取消订单可能直接变为已取消；而在已签收状态下，取消订单可能需要触发退款流程甚至被拒绝。此外，游戏角色的行为（站立、行走、跳跃）、自动售货机的投币与出货逻辑等，都非常适合使用状态模式来管理。
通过引入状态模式，我们可以将每个状态的行为独立成一个类，让状态类自己管理状态之间的转换。这不仅符合单一职责原则，也遵循了开闭原则，当需要新增一个状态时，只需新增一个状态类，而无需修改原有的条件分支逻辑。
C#中状态模式的基础结构实现
在C#中实现状态模式，通常需要三个核心角色：上下文类、抽象状态接口和具体状态类。上下文类维护一个当前状态对象的实例引用，并将与状态相关的请求委托给这个当前状态对象处理。抽象状态接口声明了所有具体状态类必须实现的方法，而具体状态类则实现了与该状态相关的行为。
首先，我们需要定义一个抽象的状态接口。假设我们正在开发一个简单的文档审批系统，文档有草稿、审核中和已发布三种状态。我们可以定义一个IDocumentState接口，包含发布和审核的方法。通过接口定义，上下文类可以依赖于抽象而非具体实现，从而实现多态调用。
public interface IDocumentState
{
void Publish(DocumentContext context);
void Review(DocumentContext context);
}
接下来，实现具体的状态类。每个状态类在执行完自身逻辑后，负责将上下文的当前状态切换到下一个合适的状态。例如，在草稿状态下执行审核操作，状态会切换到审核中；而在审核中状态下执行发布操作，状态会切换到已发布。这种设计使得状态转换的逻辑被分散到了各个状态类内部，降低了耦合度。
public class DraftState : IDocumentState
{
public void Publish(DocumentContext context)
{
Console.WriteLine("草稿状态下不能直接发布，需要先提交审核。");
}
public void Review(DocumentContext context)
{
Console.WriteLine("文档已提交审核。");
context.SetState(new ReviewState());
}
}
public class ReviewState : IDocumentState
{
public void Publish(DocumentContext context)
{
Console.WriteLine("审核通过，文档已发布。");
context.SetState(new PublishedState());
}
public void Review(DocumentContext context)
{
Console.WriteLine("文档已经在审核中，请勿重复提交。");
}
}
public class PublishedState : IDocumentState
{
public void Publish(DocumentContext context)
{
Console.WriteLine("文档已经发布，无需重复发布。");
}
public void Review(DocumentContext context)
{
Console.WriteLine("已发布的文档不能再次审核。");
}
}
最后，实现上下文类DocumentContext。它持有一个IDocumentState实例，代表当前文档的状态。上下文类不包含任何状态判断逻辑，它只是简单地将操作请求转发给当前的状态对象。同时，它提供一个方法供状态类调用以更新当前状态。
public class DocumentContext
{
private IDocumentState _currentState;
public DocumentContext()
{
// 初始状态为草稿
_currentState = new DraftState();
}
public void SetState(IDocumentState state)
{
_currentState = state;
}
public void Publish()
{
_currentState.Publish(this);
}
public void Review()
{
_currentState.Review(this);
}
}
客户端调用时，只需与上下文类交互，完全不需要关心当前处于什么状态以及状态如何转换。这种封装极大地简化了客户端的调用逻辑，使得系统更加健壮。
状态转移的维护与优化策略
在基础实现中，我们将状态转换的逻辑放在了具体的状态类中。这种方式被称为状态转移由状态类主导。它的优点是状态类封装了自己的转换逻辑，符合单一职责原则。但缺点也很明显：如果状态转换规则发生变化，或者新增了状态，可能需要修改多个现有的状态类，导致状态类之间存在隐式的依赖关系。
另一种策略是状态转移由上下文主导。在这种策略下，上下文类负责根据当前状态和操作决定下一个状态。具体状态类只负责执行当前状态下的行为，不关心后续转换。这种方式的优点是状态类更加纯粹，状态转换逻辑集中在上下文中，便于统一管理和修改。然而，这又会导致上下文类重新陷入条件分支的泥潭，违背了状态模式消除条件分支的初衷。
为了兼顾两者的优点，我们可以采用查表法或状态机框架来优化。查表法将状态、事件和下一个状态的映射关系存储在字典或配置表中。这种方式将状态转换逻辑数据化，不仅彻底消除了代码中的条件分支，还使得状态转换规则的修改变得非常简单，只需修改配置数据即可。
public enum DocumentStateEnum { Draft, Review, Published }
public enum DocumentEvent { Review, Publish }
public class DocumentContextWithTable
{
private DocumentStateEnum _currentState = DocumentStateEnum.Draft;
// 状态转移表：当前状态 + 事件 -> 下一个状态
private static readonly Dictionary<(DocumentStateEnum, DocumentEvent), DocumentStateEnum> _transitionTable =
new Dictionary<(DocumentStateEnum, DocumentEvent), DocumentStateEnum>
{
{ (DocumentStateEnum.Draft, DocumentEvent.Review), DocumentStateEnum.Review },
{ (DocumentStateEnum.Review, DocumentEvent.Publish), DocumentStateEnum.Published }
};
public void TriggerEvent(DocumentEvent ev)
{
var key = (_currentState, ev);
if (_transitionTable.TryGetValue(key, out var nextState))
{
Console.WriteLine($"状态从 {_currentState} 变更为 {nextState}");
_currentState = nextState;
}
else
{
Console.WriteLine($"在 {_currentState} 状态下无法触发 {ev} 事件");
}
}
}
此外，在实际项目中，频繁创建和销毁状态对象可能会带来一定的性能开销，特别是当状态对象内部包含较多资源时。为了优化性能，可以将状态对象设计为单例模式。由于状态对象通常不包含实例变量，只包含行为逻辑，因此多个上下文实例共享同一个状态单例是完全安全的。这不仅能减少内存分配，还能加快状态切换的速度。
结合实际业务的状态机进阶应用
在复杂的电商订单系统中，订单状态机往往涉及十几种状态和数十种事件。如果纯粹使用面向对象的状态模式，类的数量会急剧膨胀。此时，结合状态模式的思想与领域驱动设计（DDD），我们可以将订单聚合根作为上下文，将状态行为封装为值对象或策略类，从而在保持代码整洁的同时，控制类的数量。
以订单取消为例，不同状态下取消订单的后续处理逻辑差异巨大。待支付状态下取消订单，只需释放库存预占；已发货状态下取消订单，则需要发起物流拦截并准备退款流程。通过状态模式，我们可以在订单聚合根中定义Cancel()方法，并将其委托给当前的状态策略对象执行。这样，订单聚合根无需编写冗长的switch语句，代码可读性大幅提升。
public abstract class OrderState
{
public abstract void Cancel(Order order);
}
public class PendingPaymentState : OrderState
{
public override void Cancel(Order order)
{
Console.WriteLine("释放库存预占，订单已取消。");
order.ChangeState(new CancelledState());
}
}
public class ShippedState : OrderState
{
public override void Cancel(Order order)
{
Console.WriteLine("发起物流拦截，准备退款流程。");
order.ChangeState(new RefundingState());
}
}
public class Order
{
private OrderState _state;
public Order()
{
_state = new PendingPaymentState();
}
public void ChangeState(OrderState state)
{
_state = state;
}
public void Cancel()
{
_state.Cancel(this);
}
}
这种进阶应用充分体现了状态模式的扩展性。当业务需要新增一种已退款状态时，我们只需新增一个继承自OrderState的类，并在适当的地方触发状态切换即可。原有的状态类和订单聚合根代码完全不需要修改，完美契合了开闭原则。通过合理运用状态模式，我们能够构建出高内聚、低耦合的状态机架构，从容应对复杂多变的业务规则。