状态模式属于行为型设计模式，核心思路是把对象的每一个状态都封装成独立的类，对象的行为会随着当前状态的改变而发生变化，这样就能把原本分散在各个条件判断里的逻辑收敛到对应的状态类中，让代码结构更清晰。当对象的状态比较多，且不同状态下行为差异较大时，使用状态模式能有效减少代码的复杂度。
状态模式的核心角色
在Golang中实现状态模式，需要明确几个核心的角色，每个角色的职责划分清晰，才能写出结构合理的代码：
- 状态接口：定义所有具体状态需要实现的行为方法，上下文对象会通过这个接口来调用当前状态的行为
- 具体状态类：实现状态接口，每个具体状态类对应对象的一种状态，实现该状态下对应的具体行为逻辑
- 上下文对象：持有当前状态的引用，对外提供操作接口，当状态发生变化时，切换持有的状态实例
Golang实现状态模式的完整步骤
第一步：定义状态接口
首先需要根据对象的行为定义统一的状态接口，假设我们要实现一个简单的订单状态控制，订单有创建、支付、发货、完成四个状态，每个状态下允许的操作不同，先定义状态接口：
// 订单状态接口，定义订单支持的操作
type OrderState interface {
// 支付订单
Pay(ctx *OrderContext) error
// 发货
Ship(ctx *OrderContext) error
// 完成订单
Complete(ctx *OrderContext) error
// 获取当前状态名称
GetName() string
}
第二步：实现具体状态类
接下来实现每个具体状态，每个状态只处理自己状态下允许的操作，不允许的操作返回对应的错误：
import "fmt"
// 待支付状态
type UnpaidState struct{}
func (s *UnpaidState) GetName() string {
return "待支付"
}
func (s *UnpaidState) Pay(ctx *OrderContext) error {
// 待支付状态下允许支付，支付完成后切换到待发货状态
fmt.Println("订单支付成功")
ctx.SetState(&UnShippedState{})
return nil
}
func (s *UnpaidState) Ship(ctx *OrderContext) error {
return fmt.Errorf("订单未支付，无法发货")
}
func (s *UnpaidState) Complete(ctx *OrderContext) error {
return fmt.Errorf("订单未支付，无法完成")
}
// 待发货状态
type UnShippedState struct{}
func (s *UnShippedState) GetName() string {
return "待发货"
}
func (s *UnShippedState) Pay(ctx *OrderContext) error {
return fmt.Errorf("订单已支付，无需重复支付")
}
func (s *UnShippedState) Ship(ctx *OrderContext) error {
// 待发货状态下允许发货，发货完成后切换到待完成状态
fmt.Println("订单已发货")
ctx.SetState(&CompletedState{})
return nil
}
func (s *UnShippedState) Complete(ctx *OrderContext) error {
return fmt.Errorf("订单未发货，无法完成")
}
// 已完成状态
type CompletedState struct{}
func (s *CompletedState) GetName() string {
return "已完成"
}
func (s *CompletedState) Pay(ctx *OrderContext) error {
return fmt.Errorf("订单已完成，无需支付")
}
func (s *CompletedState) Ship(ctx *OrderContext) error {
return fmt.Errorf("订单已完成，无需发货")
}
func (s *CompletedState) Complete(ctx *OrderContext) error {
return fmt.Errorf("订单已完成，无需重复操作")
}
第三步：实现上下文对象
上下文对象持有当前的状态实例，对外提供操作入口，所有操作都委托给当前状态实例处理：
// 订单上下文对象
type OrderContext struct {
// 当前状态
currentState OrderState
// 订单ID
orderId string
}
// 初始化订单上下文，默认是待支付状态
func NewOrderContext(orderId string) *OrderContext {
return &OrderContext{
orderId: orderId,
currentState: &UnpaidState{},
}
}
// 设置当前状态
func (o *OrderContext) SetState(state OrderState) {
o.currentState = state
}
// 获取当前状态名称
func (o *OrderContext) GetCurrentState() string {
return o.currentState.GetName()
}
// 支付订单
func (o *OrderContext) Pay() error {
return o.currentState.Pay(o)
}
// 发货
func (o *OrderContext) Ship() error {
return o.currentState.Ship(o)
}
// 完成订单
func (o *OrderContext) Complete() error {
return o.currentState.Complete(o)
}
第四步：测试状态模式效果
编写测试代码验证状态模式的运行效果，观察不同状态下对象的行为是否符合预期：
func main() {
// 创建订单，初始状态为待支付
order := NewOrderContext("ORDER_001")
fmt.Printf("当前订单状态：%sn", order.GetCurrentState())
// 待支付状态下尝试发货，会返回错误
err := order.Ship()
if err != nil {
fmt.Printf("操作失败：%sn", err.Error())
}
// 待支付状态下支付，状态切换为待发货
err = order.Pay()
if err != nil {
fmt.Printf("操作失败：%sn", err.Error())
}
fmt.Printf("当前订单状态：%sn", order.GetCurrentState())
// 待发货状态下发货，状态切换为已完成
err = order.Ship()
if err != nil {
fmt.Printf("操作失败：%sn", err.Error())
}
fmt.Printf("当前订单状态：%sn", order.GetCurrentState())
// 已完成状态下尝试支付，会返回错误
err = order.Pay()
if err != nil {
fmt.Printf("操作失败：%sn", err.Error())
}
}
运行上述代码，输出结果如下：
当前订单状态：待支付 操作失败：订单未支付，无法发货 订单支付成功 当前订单状态：待发货 订单已发货 当前订单状态：已完成 操作失败：订单已完成，无需支付
状态模式的优势与适用场景
使用Golang实现状态模式后，能带来几个明显的优势：
- 避免了大量的if-else或者switch-case条件判断，把状态相关的逻辑收敛到对应的状态类中，符合单一职责原则
- 新增状态时只需要新增一个具体状态类，不需要修改现有代码，符合开闭原则，扩展性更好
- 状态之间的切换逻辑清晰，每个状态的行为独立，代码可读性和可维护性更高
状态模式适合用在对象的行为依赖自身状态，且状态比较多、状态之间切换逻辑复杂的场景，比如订单状态流转、游戏角色状态控制、工作流状态管理等场景，都能通过状态模式简化代码结构。
注意事项
在Golang中实现状态模式时，需要注意几个细节：
- 状态接口的方法定义要覆盖对象所有可能需要的行为，避免后续新增行为时需要修改所有状态类
- 如果状态之间共享一些通用逻辑，可以把通用逻辑放到上下文对象中，或者通过组合的方式复用代码
- 状态的切换最好由状态类自身触发，还是由上下文对象触发，需要根据实际业务场景决定，通常推荐由状态类触发状态切换，让状态的逻辑更内聚