如何避免使用布尔标志？此类单次触发逻辑是否为代码坏味道？

嘿，这个问题问得很实在！咱们先拆解一下你的实现方案，再聊聊怎么让代码更优雅。

你的方案算不算“代码坏味道”？ #

首先得说：这种布尔标志的写法本身不算绝对的坏味道——在简单场景下，它是一种直观、容易理解的实现方式。但它确实存在一些潜在的问题，会随着业务逻辑变复杂逐渐演变成坏味道：

• 可读性隐患：如果标志的命名不够精准（比如随便叫flag或者done），后续维护的开发者可能要花时间理清这个标志到底控制什么逻辑。
• 状态管理混乱：如果后续需要添加多个一次性执行的逻辑，或者有重置状态的需求，多个布尔标志交织在一起很容易出现漏改、错改的情况。
• 职责耦合：标志判断和业务逻辑混在同一个函数里，函数的职责变得不单一——既要处理核心业务，又要管理执行状态。

你的示例里isInited命名还算清晰，但如果场景扩展（比如需要满足多个条件、或者有多个一次性代码块），这种写法的弊端就会凸显出来。

如何避免这类布尔标志？ #

根据不同的场景，有几种更优雅的替代方案：

1. 用闭包封装“一次性执行”逻辑 #

把控制执行次数的逻辑抽成通用工具，业务代码只需要关注要执行的内容，不用管状态管理：

func once(_ block: @escaping () -> Void) -> () -> Void {
    var hasExecuted = false
    return {
        guard !hasExecuted else { return }
        hasExecuted = true
        block()
    }
}

// 使用示例
var amount: Int = 0
// 定义只会执行一次的初始化逻辑
let runInitOnce = once {
    // 这里放你需要只执行一次的代码
    print("初始化逻辑执行了")
}

func thatFunctionRunsManyTimes() {
    if amount > 3 {
        runInitOnce() // 不管调用多少次，内部只会执行一次
    }
    // 其他业务代码
    amount += 1
}

这种方式把“一次性执行”的逻辑封装成独立工具，业务代码更干净，可读性也更强。

2. 提取独立逻辑，明确执行时机 #

把需要只执行一次的代码抽成单独的函数，然后在合适的时机触发它，而不是在重复执行的函数里做判断：

var amount: Int = 0

// 独立封装一次性逻辑
func performInitialization() {
    // some additional code
    print("初始化完成")
}

func thatFunctionRunsManyTimes() {
    // 其他业务代码
    amount += 1
    
    // 把判断逻辑放在这里，或者移到调用方更合适的位置
    if amount > 3 {
        performInitialization()
        // 如果需要确保只执行一次，可以在这里添加一个标记，或者把判断逻辑改为触发后不再检查
        // 比如可以把amount的判断改成：amount == 4（假设初始是0，第四次调用时满足）
    }
}

这种方式适合逻辑比较简单的场景，能让函数职责更单一——thatFunctionRunsManyTimes只负责核心业务，初始化逻辑单独管理。

3. 状态机模式（适合复杂场景） #

如果你的业务有多个状态（不止“未执行/已执行”），用状态机来管理状态变化会更清晰：

// 定义状态枚举
enum ComponentState {
    case uninitialized
    case initialized
}

class SomeComponent {
    var amount: Int = 0
    private var state: ComponentState = .uninitialized

    func thatFunctionRunsManyTimes() {
        // 根据状态和条件决定是否执行初始化
        switch state {
        case .uninitialized where amount > 3:
            // 执行初始化逻辑
            print("执行初始化")
            state = .initialized
        default:
            break
        }
        
        // 核心业务代码
        amount += 1
    }
}

状态机的好处是状态变化一目了然，后续如果要添加新状态（比如“初始化中”），可以直接扩展枚举，代码的可维护性会大幅提升。

4. 利用语言特性（比如Swift的lazy属性） #

如果你的一次性逻辑是类的初始化相关操作，可以结合lazy属性来实现延迟执行且仅执行一次：

class SomeClass {
    var amount: Int = 0
    // lazy属性只会在第一次访问时执行
    private lazy var initialized: Bool = {
        // 这里放一次性执行的初始化代码
        print("通过lazy属性执行初始化")
        return true
    }()

    func thatFunctionRunsManyTimes() {
        if amount > 3 {
            // 访问lazy属性触发初始化
            _ = initialized
        }
        // 核心业务代码
        amount += 1
    }
}

不过这个方案更适合“满足条件后首次触发就执行”的场景，因为lazy属性一旦被访问就无法重置。

总结 #

你的初始方案在简单场景下完全可以用，但当业务逻辑变复杂时，建议根据场景选择更合适的优化方式：

• 简单一次性逻辑：闭包封装或提取独立函数
• 多状态场景：状态机模式
• 类初始化场景：利用语言特性（如lazy）

内容的提问来源于stack exchange，提问作者mmm