一、为什么需要跨类方法调用？核心痛点是什么？

在iOS开发中，??模块化设计??和??代码解耦??是项目架构的核心要求。当两个独立类需要交互时，直接引用实例会产生强耦合关系，导致??维护成本激增??和??单元测试困难??。例如订单模块需要更新用户积分，直接调用用户模块方法会形成循环依赖。

二、代理模式：最经典的解耦方案

??适用场景??：1对1通信、父子控制器交互
??实现原理??：

• 定义协议声明方法（Protocol）
• 被调用类持有weak类型代理对象
• 调用方实现协议方法

swift复制
// 协议定义
protocol DataUpdateDelegate: AnyObject {
    func didReceiveData(_ data: String)
}

// 调用方实现
class ViewController: DataUpdateDelegate {
    func didReceiveData(_ data: String) {
        print("接收到数据：\(data)")
    }
}

??优势??：

• ??类型安全??：编译器检查方法实现
• ??内存安全??：weak引用避免循环
• ??职责清晰??：接口与实现分离

三、通知中心：一对多的广播机制

??最佳实践场景??：

• 全局状态变更（如用户登录态）
• 多个模块需要同步更新
• 无直接关联的组件通信

objective复制
// 发送通知
[[NSNotificationCenter defaultCenter] postNotificationName:@"NetworkStatusChanged" object:@(isConnected)];

// 接收处理
[[NSNotificationCenter defaultCenter] addObserver:self 
                                        selector:@selector(handleNotification:) 
                                            name:@"NetworkStatusChanged" 
                                          object:nil];

??注意事项??：

• ??字符串硬编码问题??：建议使用常量定义
• ??内存泄漏风险??：必须显式移除观察者
• ??调试困难??：需要全局搜索通知名

四、闭包回调：Swift的现代化方案

??对比代理模式??：

??实战技巧??：

• 使用[weak self]避免循环引用
• 类型别名提升可读性（typealias）
• 可选闭包处理异常情况

swift复制
class DataLoader {
    var completionHandler: ((Result<String, Error>) -> Void)?
    
    func fetchData() {
        // 网络请求成功后
        completionHandler?(.success("新数据"))
    }
}

五、单例模式：全局访问的利与弊

??争议焦点??：

• 优点：快速实现跨模块访问（如UserDefaults标准方案）
• 缺点：??破坏单元测试??、??隐藏依赖关系??

??改进方案??：

1. 依赖注入替代全局访问
2. 协议约束单例功能
3. 使用Swift的enum实现线程安全单例

六、KVO观察者模式：特定场景的最后选择

??使用现状??：

• Swift中基本被Combine框架替代
• 仅推荐在遗留Objective-C项目中使用
• 需要手动处理观察者注册/注销

??致命缺陷??：

• ??键路径字符串??易引发崩溃
• 多次注册导致重复触发
• 继承关系中的意外观察

从项目经验来看，??简单回调优先使用闭包??，模块间通信采用代理模式，全局事件用通知中心。新项目建议尝试Combine框架的@Published属性包装器，这可能是未来跨类通信的更优解。注意避免陷入「设计模式滥用」的陷阱，有时候直接依赖注入反而比过度设计更高效。