企业项目管理、ORK、研发管理与敏捷开发工具平台

网站首页 > 精选文章 正文

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

wudianyun 2025-07-09 18:03:55 精选文章 6 ℃

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


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

相信每个移动端开发者都写过类似这样的代码:
随着业务复杂度提升,你的 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逻辑、网络层切换,策略模式都可以极大优化代码结构。
掌握它,你的工程就能从“分支地狱”进化为“灵活应变的工厂”。


Tags:

最近发表
标签列表