告别冗长分支！策略模式让你的代码更优雅

引言：分支地狱与代码维护噩梦

相信每个移动端开发者都写过类似这样的代码：
随着业务复杂度提升，你的 if-else/switch 分支越来越长、越来越难读、每加一个新功能就要修改一大片。比如 App 中的消息分发、不同类型的推送、表单校验、支付渠道、UI 渲染方式……
分支判断写多了，维护和扩展就像走钢丝，一不小心就出 bug，团队协作也越来越困难。
有没有一种办法，把这些“分支地狱”优雅拆解？本期就带你用策略模式彻底解决！

1. 生活中的分支困局：问题与痛点

假设我们有一个 App，支持多种登录方式（如手机号、微信、Apple ID、邮箱等）。最直接的做法是这样：

    
    
    
  func login(type: LoginType, credential: String) {
    if type == .phone {
        // 手机号登录
    } else if type == .wechat {
        // 微信登录
    } else if type == .apple {
        // Apple ID登录
    } else if type == .email {
        // 邮箱登录
    }
}

Kotlin 写法也类似：

    
    
    
  fun login(type: LoginType, credential: String) {
    when (type) {
        LoginType.PHONE -> { /* 手机号登录 */ }
        LoginType.WECHAT -> { /* 微信登录 */ }
        LoginType.APPLE -> { /* Apple ID登录 */ }
        LoginType.EMAIL -> { /* 邮箱登录 */ }
    }
}

这样写有哪些问题？

• o 分支不断膨胀，代码臃肿。 新增一种登录方式就得加一个分支，主流程越来越乱。
• o 高耦合、难维护。 登录流程与具体实现混在一起，逻辑难拆分，协作易冲突。
• o 可扩展性差。 想加新功能、新验证，得改主流程，容易引发连锁 bug。
• o 违背开闭原则。 每次需求变动都要“开肠破肚”修改原有流程。

2. 策略模式的核心思想

**策略模式（Strategy Pattern）**属于行为型设计模式。
它的核心就是：把一组易变的算法/逻辑封装成独立的策略对象，客户端通过组合和切换策略，灵活实现不同业务处理，而不依赖具体实现。

通俗地说：

• o 用“多态”代替分支，把分支的每个 case 拆成独立的“策略类”，用统一接口约束。
• o 新增/切换算法，无需动主流程，扩展性极强。
• o 流程只关心“要做什么”，而不关心“怎么做”。

结构图简述：

• o Context（上下文）：主流程，只依赖策略接口。
• o Strategy（策略接口）：所有策略的统一父类。
• o ConcreteStrategy（具体策略）：不同业务逻辑独立实现。

3. Swift & Kotlin 实战：重构分支判断

3.1 策略接口定义

    
    
    
  protocol LoginStrategy {
    func login(credential: String)
}

    
    
    
  interface LoginStrategy {
    fun login(credential: String)
}

3.2 各种策略实现

    
    
    
  class PhoneLogin: LoginStrategy {
    func login(credential: String) {
        print("使用手机号 \(credential) 登录")
    }
}
class WeChatLogin: LoginStrategy {
    func login(credential: String) {
        print("使用微信 \(credential) 登录")
    }
}
class AppleLogin: LoginStrategy {
    func login(credential: String) {
        print("使用Apple ID \(credential) 登录")
    }
}
class EmailLogin: LoginStrategy {
    func login(credential: String) {
        print("使用邮箱 \(credential) 登录")
    }
}

    
    
    
  class PhoneLogin : LoginStrategy {
    override fun login(credential: String) {
        println("使用手机号 $credential 登录")
    }
}
class WeChatLogin : LoginStrategy {
    override fun login(credential: String) {
        println("使用微信 $credential 登录")
    }
}
class AppleLogin : LoginStrategy {
    override fun login(credential: String) {
        println("使用Apple ID $credential 登录")
    }
}
class EmailLogin : LoginStrategy {
    override fun login(credential: String) {
        println("使用邮箱 $credential 登录")
    }
}

3.3 上下文类（Context）只组合策略

    
    
    
  class LoginContext {
    private var strategy: LoginStrategy
    init(strategy: LoginStrategy) {
        self.strategy = strategy
    }
    func login(credential: String) {
        strategy.login(credential: credential)
    }
    func setStrategy(_ strategy: LoginStrategy) {
        self.strategy = strategy
    }
}

    
    
    
  class LoginContext(private var strategy: LoginStrategy) {
    fun login(credential: String) {
        strategy.login(credential)
    }
    fun setStrategy(strategy: LoginStrategy) {
        this.strategy = strategy
    }
}

3.4 客户端调用示例

    
    
    
  let phoneLogin = PhoneLogin()
let weChatLogin = WeChatLogin()
let context = LoginContext(strategy: phoneLogin)
context.login(credential: "13800138000")
context.setStrategy(weChatLogin)
context.login(credential: "wxid_xxx")

    
    
    
  val phoneLogin = PhoneLogin()
val weChatLogin = WeChatLogin()
val context = LoginContext(phoneLogin)
context.login("13800138000")
context.setStrategy(weChatLogin)
context.login("wxid_xxx")

4. 策略模式在移动端的其他应用场景

• o 多渠道推送消息： 不同推送渠道封装为不同策略，客户端灵活切换（极光/个推/本地推送等）。
• o 表单验证/数据校验： 各种校验策略独立实现，灵活组合，满足复杂业务定制。
• o 图片加载/缓存策略： 不同类型图片、不同缓存方式，策略灵活切换（如内存、磁盘、只缓存缩略图等）。
• o 动画/渲染策略切换： 白天/夜间主题、动态/静态切换等场景。
• o 价格/优惠计算策略： 电商 App 促销、满减、积分等复杂价格逻辑独立实现。

5. 策略模式的优缺点与使用建议

优点

• o 拆分复杂分支，主流程更清晰，维护成本低。
• o 新增业务“零侵入”，扩展极其方便。
• o 有利于单元测试、持续集成和团队分工。
• o 灵活组合，可运行时切换算法。

缺点

• o 策略类较多时，管理可能复杂（推荐结合依赖注入、注册表/工厂模式）。
• o 不适用于分支极少的简单逻辑，避免“过度设计”。

实践建议

• o 策略接口应“小而专”，每个策略类聚焦单一业务逻辑。
• o 结合依赖注入/配置中心，支持热更新和灵活切换。
• o 场景复杂时，推荐将策略注册到容器/工厂中统一管理。

6. 结语

策略模式并不难理解，本质就是用“多态”代替“分支”，让代码更可维护、更具扩展力。
在实际 App 开发中，无论是业务层拆分、UI逻辑、网络层切换，策略模式都可以极大优化代码结构。
掌握它，你的工程就能从“分支地狱”进化为“灵活应变的工厂”。