状态模式通过封装不同状态行为消除冗长条件判断，提升代码可维护性。以订单系统为例，定义OrderState接口并为“待支付”、“已支付”等状态实现具体逻辑，订单结构体持有当前状态并将操作委托给状态实例，实现行为随状态改变而变化，新增状态无需修改现有代码，符合开闭原则，使系统更易扩展和维护。
在go语言中，当业务逻辑中出现大量基于状态的 if-else 或 switch-case 判断时，代码会变得难以维护。状态模式通过将每种状态封装为独立的行为对象，有效消除冗长的条件判断，提升可读性和扩展性。
状态模式的核心思想
状态模式允许一个对象在其内部状态改变时改变其行为。我们把每个状态定义为一个接口实现，对象的行为委托给当前状态实例，而不是用条件语句判断该做什么。
以订单系统为例：订单有“待支付”、“已支付”、“已发货”、“已完成”等状态，不同状态下对“支付”、“发货”、“取消”等操作的响应各不相同。
定义状态接口与具体状态
先定义统一的状态接口：
立即学习“go语言免费学习笔记（深入）”；
type OrderState interface { Pay(order *Order) Ship(order *Order) Complete(order *Order) Cancel(order *Order) }
然后为每种状态实现该接口。例如“待支付”状态：
type PendingState struct{} func (s *PendingState) Pay(order *Order) { fmt.Println("订单已支付") order.setState(&PaidState{}) } func (s *PendingState) Ship(order *Order) { fmt.Println("无法发货：订单未支付") } func (s *PendingState) Complete(order *Order) { fmt.Println("无法完成：订单未发货") } func (s *PendingState) Cancel(order *Order) { fmt.Println("订单已取消") order.setState(&CancelledState{}) }
“已支付”状态只能发货或取消，不能再次支付：
type PaidState struct{} func (s *PaidState) Pay(order *Order) { fmt.Println("订单已支付，无需重复操作") } func (s *PaidState) Ship(order *Order) { fmt.Println("已发货") order.setState(&ShippedState{}) }
订单上下文管理状态切换
订单结构体持有当前状态，并将操作委托给状态对象：
type Order struct { state OrderState } func Neworder() *Order { return &Order{state: &PendingState{}} } func (o *Order) setState(state OrderState) { o.state = state } // 委托调用 func (o *Order) Pay() { o.state.Pay(o) } func (o *Order) Ship() { o.state.Ship(o) } func (o *Order) Complete() { o.state.Complete(o) } func (o *Order) Cancel() { o.state.Cancel(o) }
使用示例与优势
客户端代码简洁直观：
order := NewOrder() order.Pay() // 输出：订单已支付 order.Ship() // 输出：已发货 order.Complete() // 输出：订单已完成 order.Cancel() // 输出：无法取消：已完成订单
相比一堆 if-else 判断当前状态再执行逻辑，状态模式：
- 新增状态只需添加新结构体并实现接口，符合开闭原则
- 每个状态逻辑独立，便于测试和维护
- 避免了散落在多处的条件分支，降低出错概率
基本上就这些。状态模式特别适合状态较多、状态间转换复杂、每个状态行为差异大的场景。在Go中利用接口和组合，能很干净地实现这一模式，让代码更清晰。
评论（已关闭）
评论已关闭