别盲目用设计模式替代if else，真没那么香！

刚接触编程的时候，我和很多人一样，觉得代码里的if else越少越好，总想着用各种设计模式去优化它。但随着经验的积累，我发现事情远没有那么简单。今天就来和大家聊聊，为啥不能一股脑地用设计模式消除if else。先给大家划下重点：
1. 实现功能要恰到好处，别给代码加太多没根据的假设。
2. 过早套用设计模式，可能会让代码灵活性大打折扣，虽然这有点反直觉，但事实就是如此。
3. 状态模式和策略模式不一定是万能解药，有时候简单直接的if - else反而更直观好用。
4. 工厂模式可以在代码清理、演进的过程中自然引入，不用强行套用。

if else真的一无是处吗？

如果一个功能用三个if逻辑判断就能轻松搞定，真没必要大费周章地用设计模式封装。咱们编程的目的是高效实现功能，提高扩展性和性能，而不是单纯为了减少if else而优化。学了设计模式后，大家难免会有“拿着锤子找钉子”的心态，总想用它改造代码。可很多时候改完再看，会忍不住问自己：为啥把代码写这么复杂？明明几个if else就能解决，非要用上工厂模式和策略模式。要是状态就两三种，直接用if判断状态机状态就好，为啥非要改成状态模式，感觉就是为了封装而封装。

实际上，如果一个功能里if到处都是，那大概率啥设计模式都救不了，强行用只会让代码更混乱。想要真正优化if else，不妨画个流程图，梳理下业务流程，去掉那些多余的逻辑，这才是从根本上解决问题。

状态模式消除if else，真的好吗？

咱们来看个具体例子，购物订单创建后是等待支付状态（pending），用户支付后变成已支付（paid），只有未支付的订单能取消（cancel）。

先看看用if else实现的代码：

func CreateOrder() Order { // 在数据库中创建订单 return Order{ State: Pending, } } func PaidOrder(order Order) error { // 未支付的订单才能支付 if order.State != Pending { return errors.New("order state is not pending") } // 更新订单状态到数据库 order.State = Paid //... return nil } func CancelOrder(order Order) error { // 只有订单状态为Pending时才能取消 if order.State != Pending { return errors.New("order state is not pending") } // 更新订单状态到数据库 order.State = Cancel //... return nil }

因为订单状态少，这样实现既简洁又直观。但要是非要用状态机模式封装，虽然能去掉if判断状态的代码，却会引入更复杂的代码。

下面是状态机实现后的代码：

// OrderState定义订单状态行为 type OrderState interface { Paid(order *Order) error Cancel(order *Order) error GetState() int } // PendingState待支付状态 type PendingState struct{} func (s *PendingState) Paid(order *Order) error { // 更新订单状态到数据库 order.OrderState = &PaidState{} fmt.Println("订单已支付") return nil } func (s *PendingState) Cancel(order *Order) error { // 更新订单状态到数据库 order.OrderState = &CanceledState{} fmt.Println("订单已取消") return nil } func (s *PendingState) GetState() int { return Pending } // PaidState已支付状态 type PaidState struct{} func (s *PaidState) Paid(order *Order) error { return errors.New("订单已支付，不能再次支付") } func (s *PaidState) Cancel(order *Order) error { return errors.New("订单已支付，不能取消") } func (s *PaidState) GetState() int { return Paid } // CanceledState已取消状态 type CanceledState struct{} func (s *CanceledState) Paid(order *Order) error { return errors.New("订单已取消，不能支付") } func (s *CanceledState) Cancel(order *Order) error { return errors.New("订单已取消，不能重复取消") } func (s *CanceledState) GetState() int { return Cancel } // CreateOrder创建一个新订单，默认状态为Pending func CreateOrder() *Order { return &Order{ OrderState: &PendingState{}, } } // PaidOrder支付订单 func PaidOrder(order *Order) error { return order.OrderState.Paid(order) } // CancelOrder取消订单 func CancelOrder(order *Order) error { return order.OrderState.Cancel(order) }

乍一看，代码好像变得“高大上”了，但仔细分析就会发现问题。

符合单一职责原则（SRP）？未必！

状态机模式下，每个状态类只处理相关逻辑，理论上修改“已支付”状态逻辑，不会影响其他状态。但用if else实现时，修改PaidOrder方法，改动范围也不大，所以这个所谓的“好处”并不明显。

代码更具扩展性？不一定！

有人说状态机模式符合开闭原则（OCP），新增状态或行为时，不用修改现有代码，直接添加新状态类就行。但实际真的如此吗？比如增加退款操作，就得在OrderState接口添加RefundedState方法，每个状态实现类都得增加这个方法。

有人可能会说，可以增加一个通用错误状态类来解决。但如果每个错误状态的报错文案不同且无规律，这个通用实现就没用了。

相比之下，if else实现增加新状态时，改动范围往往比想象的小。比如增加支付订单能转成已发货状态，确认收货后完成订单的功能，用if else实现，不需要改动之前的代码，直接增加新操作就行。

func ShippedOrder(order Order) error { // 只有订单状态为Paid时才能发货 if order.State != Paid { return errors.New("order state is not paid") } // 更新订单状态到数据库 order.State = Shipped //... return nil } func CompleteOrder(order Order) error { // 只有订单状态为Shipped时才能完成 if order.State != Shipped { return errors.New("order state is not shipped") } // 更新订单状态到数据库 order.State = Complete //... return nil }

要是增加支持先发货再支付，最终完成订单的功能呢？只需要增加一个map维护操作的有效状态，再增加一个验证订单状态的方法就行。

var ( orderAction2ValidState = map[OrderAction][]State{ OrderActionPay: {Pending}, OrderActionShip: {Paid}, OrderActionComplete: {Shipped}, OrderActionCancel: {Pending}, } ) func ValidOrderState(order Order, action OrderAction) bool { validStates, ok := orderAction2ValidState[action] if!ok { return false } for _, state := range validStates { if order.State == state { return true } } return false }

改造原有代码后，支持先发货再付款，只需要修改orderAction2ValidState就可以。

var ( orderAction2ValidState = map[OrderAction][]State{ OrderActionPay: {Pending, Shipped}, OrderActionShip: {Paid}, OrderActionComplete: {Shipped, Paid}, OrderActionCancel: {Pending}, } )

这么看来，状态机模式的开闭原则并没有给代码修改带来实际好处。

避免复杂的条件判断？没做到！

状态机模式声称能避免复杂的条件判断，让代码更清晰。但通过map改造if else后，状态维护在orderAction2ValidState里，通过action就能对应状态，条件判断并不复杂。

代码可读性更强？不见得！

状态机模式下，逻辑是结构化了，但想看支付逻辑，还得理解状态机的封装逻辑，不如直接看PaidOrder函数直观。

易于调试和测试？也不尽然！

状态机模式说每个状态行为封装在各自类中，方便单独测试和调试。但测试ShippedOrder时，用if else实现反而少了构造状态机的代码，测试起来更方便。

策略模式消除if else，也有“坑”！

策略模式和工厂方法也常用来消除if else，效果如何呢？看个例子，不同用户有不同的打折策略：普通用户不打折，VIP用户打八折，SVIP用户打五折。

先用直译的方式实现：

func CalculatePrice(user User, price float64) float64 { // 8折 if user.CustomerType == VIP { return price * 0.8 } // 5折 if user.CustomerType == SVIP { return price * 0.5 } return price }

通过提前返回，代码看起来挺简洁。这个时候，有人可能想用策略模式和工厂模式封装。

先定义折扣策略接口：

type DiscountStrategy interface { Calculate(price float64) float64 }

然后不同用户实现不同折扣策略：

type RegularUserDiscount struct{} func (r *RegularUserDiscount) Calculate(price float64) float64 { return price // 无折扣 } type VIPUserDiscount struct{} func (v *VIPUserDiscount) Calculate(price float64) float64 { return price * 0.8 // 8折 } type SVIPUserDiscount struct{} func (s *SVIPUserDiscount) Calculate(price float64) float64 { return price * 0.5 // 5折 }

通过用户类型调用不同折扣策略计算：

var ( DiscountStrategyMap = map[CustomerType]DiscountStrategy{ Regular: &RegularUserDiscount{}, VIP: &VIPUserDiscount{}, SVIP: &SVIPUserDiscount{}, } ) func CalculatePrice(user User, price float64) float64 { strategy := DiscountStrategyMap[user.CustomerType] return strategy.Calculate(price) }

根据函数是“第一公民”的特性，还能进一步简化代码：

type CalculateHandle func(float64) float64 func (c CalculateHandle) Calculate(price float64) float64 { return c(price) } func VIPDiscountCalculate(price float64) float64 { return price * 0.8 } func RegularDiscountCalculate(price float64) float64 { return price * 0.9 } func SVIPDiscountCalculate(price float64) float64 { return price * 0.5 }

这样通过类型转换实现DiscountStrategy接口：

var ( calculateFunc = map[CustomerType]CalculateHandle{ VIP: VIPDiscountCalculate, SVIP: SVIPDiscountCalculate, Regular: RegularDiscountCalculate, } ) func CalculatePrice(user User, price float64) float64 { handle, ok := calculateFunc[user.CustomerType] if!ok { return price } return handle.Calculate(price) }

封装后代码结构化了，看起来后续增加新用户类型，只需要增加相应的折扣计算方法就行。但问题来了！

代码存在过多假设

产品提出新需求，SVIP打完折后满300减30，VIP用户满500减30。这和之前的封装预想不同，之前是按用户类型抽象折扣策略，现在满减策略是按折扣类型抽象，不同的抽象角度让代码理解和修改都变得困难。

站在“现在”看“现在”，别盲目预测未来

有人可能会说，要是一开始按折扣配置方式封装就好了。但这就像炒股，我们没办法预知未来。现实需求也是如此，很多设计模式是站在“上帝视角”解决问题，对于已有项目重构优化可能有用，但对于需求不确定的产品，过度假设和抽象会限制代码灵活性。过早使用设计模式，后续需求可能得迁就之前的设计，反而不利于扩展。

不做超出功能的封装

还是用if else实现，从折扣角度进行封装：

type Discount struct { // 折扣率 DiscountRate float64 } func (d *Discount) Calculate(price float64) float64 { return price * d.DiscountRate } type FullDiscount struct { // 满多少钱可以减 TargetPrice float64 // 减多少钱 Discount float64 } func (f *FullDiscount) Calculate(price float64) float64 { if price >= f.TargetPrice { return price - f.Discount } return price } func getDiscounts(customerType CustomerType) []DiscountStrategy { if customerType == VIP { return []DiscountStrategy{ &Discount{DiscountRate: 0.8}, &FullDiscount{TargetPrice: 500, Discount: 30}, } } if customerType == SVIP { return []DiscountStrategy{ &Discount{DiscountRate: 0.5}, &FullDiscount{TargetPrice: 300, Discount: 30}, } } return []DiscountStrategy{ &Discount{DiscountRate: 1}, } } func Calculate(user User, price float64, discount Discount) float64 { // 获取折扣策略，这个可以支持配置 strategies := getDiscounts(user.CustomerType) // 给价格应用折扣策略 for _, strategy := range strategies { price = strategy.Calculate(price) } return price }

这种方式保留了if else，但修改了构造折扣的方式。代码清晰易懂，能快速知道不同用户的折扣，还支持折扣链构造，完美实现当前需求，也没有引入多余假设。

如果后续折扣要支持配置，修改getDiscounts的构造就行，还能在局部进行策略缓存优化，不会影响折扣计算逻辑。这里假设做缓存是因为缓存属于技术层面，不依赖业务变化，即使假设不成立，也不影响需求迭代，和对业务需求的假设不同。

结构化代码能够减少修改带来的错误

当业务需求稳定，需要优化性能时，如果代码结构混乱，确实很难下手。这个时候合理的封装就很有必要，重构代码增加缓存优化时，也能避免出现BUG。通过抽象出getDiscounts，给它增加单元测试，改变配置看获取的折扣是否符合预期，就能保证计算金额的准确性。这样代码更“可测试”，性能优化也更方便，测试范围缩小，编写测试用例也更简单。

工厂模式，别着急用！

工厂模式和策略模式类似，如果产品方向不明确，没有确定的抽象，先别急着用。就像Kubernetes中proxy的Provider，最初v1.0.0版本直接依赖Proixer的iptables具体实现，等第一版功能完整后，才开始抽象出Provider接口。

// Provider is the interface provided by proxier implementations. type Provider interface { config.EndpointSliceHandler config.ServiceHandler config.NodeHandler config.ServiceCIDRHandler Sync() SyncLoop() }

它不是一开始就进行抽象，而是先实现功能，在隔离上下层时总结出抽象方式。对于业务代码也是如此，一开始就创建抽象会限制上层业务变化。

工厂模式通过OOP思想内聚相同内容，开发时不用刻意套用。随着代码发展，自然会用到。还是以Kubernetes的Provider为例，抽象出Provider后，增加IPVS和nftables时，通过createProxier实例化，就用到了工厂模式的思想。

func (s *ProxyServer) createProxier(...) (proxy.Provider, error) { var proxier proxy.Provider if config.Mode == proxyconfigapi.ProxyModeIPTables { if dualStack { proxier, err = iptables.NewDualStackProxier() } else { proxier, err = iptables.NewProxier() } } else if config.Mode == proxyconfigapi.ProxyModeIPVS { if dualStack { proxier, err = ipvs.NewDualStackProxier() } else { proxier, err = ipvs.NewProxier() } } else if config.Mode == proxyconfigapi.ProxyModeNFTables { if dualStack { proxier, err = nftables.NewDualStackProxier() } else { proxier, err = nftables.NewProxier() } } return proxier, nil }

这种写法虽然不是标准的工厂模式，但直观明了。如果恰到好处能完成需求了，那我们没必要为了还未出现的需求去做后续的假设。

正确看待设计模式与if else

通过上面的例子可以看出，设计模式虽然强大，但并非解决所有if else问题的万能钥匙。在实际编程中，我们要根据具体情况来选择合适的方案。

设计模式是前人在大量实践中总结出来的经验，它们提供了通用的解决方案，能解决一些常见的软件设计问题。比如当业务逻辑变得复杂，if else嵌套过多，代码难以维护时，合理运用设计模式可以让代码结构更清晰，提高可维护性和扩展性。但这并不意味着我们要在所有情况下都使用设计模式，很多时候简单的if else语句就足以完成任务，而且它们更直观、更易于理解和调试。

在决定是否使用设计模式时，我们需要考虑以下几点：
1. 业务复杂度：如果业务逻辑简单，用if else就能清晰地表达逻辑，那就没必要使用设计模式。比如一个简单的用户权限判断，根据用户角色（普通用户、管理员）执行不同操作，用if else即可。但如果业务逻辑非常复杂，涉及多个状态的转换、多种策略的选择，并且这些逻辑会频繁变动，那么设计模式可能是更好的选择。
2. 代码的可维护性：设计模式的目的之一是提高代码的可维护性，但如果使用不当，反而会增加代码的复杂性。在使用设计模式时，要确保团队成员都能理解和维护代码。如果一个设计模式过于复杂，只有少数人能理解，那么在后续的开发和维护中可能会带来问题。
3. 可扩展性：设计模式通常能提高代码的可扩展性，当需求发生变化时，更容易进行修改和扩展。但在某些情况下，简单的if else也可以通过合理的代码结构和注释来实现较好的扩展性。例如，在一个简单的配置文件读取逻辑中，通过if else判断不同的配置项，只要代码结构清晰，后续添加新的配置项也不会太困难。
4. 性能影响：设计模式可能会引入一些额外的开销，如对象的创建、方法的调用等。在对性能要求较高的场景中，需要谨慎考虑设计模式的使用，确保不会对系统性能产生负面影响。