Swift中用convenience init替代Java/Kotlin的abstract是否合理？有何更佳方案？

一、子类用convenience init传递URL的方式是否常见？ #

这种方式在Swift社区里不算主流实践。convenience init的设计目的是提供便捷的初始化入口，辅助类的指定初始化器完成配置，而非用来模拟Java/Kotlin中抽象类强制子类提供参数的场景。如果用它来传递子类特有的配置（比如请求URL），会导致初始化逻辑碎片化，也难以统一约束所有子类的配置规则。

二、更优的实现方案推荐 #

1. 用协议替代抽象类思路 #

Swift没有原生的抽象类，但可以通过协议定义ViewModel的核心契约，要求遵循者提供必要配置，这更贴合Swift的协议导向编程风格：

// 定义协议，明确ViewModel必须具备的能力和配置
protocol RequestViewModel {
    var requestURL: URL { get }
    func fetchData(completion: @escaping (Result<Data, Error>) -> Void)
}

// 基础类封装通用网络逻辑
class BaseViewModel: RequestViewModel {
    let requestURL: URL
    
    // 指定初始化器直接接收URL，逻辑更清晰
    init(requestURL: URL) {
        self.requestURL = requestURL
    }
    
    func fetchData(completion: @escaping (Result<Data, Error>) -> Void) {
        // 调用你的通用网络层发起请求
        NetworkLayer.performRequest(url: requestURL, completion: completion)
    }
}

// 子类直接通过父类指定初始化器传入URL，无需convenience init
class UserListViewModel: BaseViewModel {
    init() {
        guard let url = URL(string: "https://api.example.com/users") else {
            fatalError("Invalid user list URL")
        }
        super.init(requestURL: url)
    }
}

这种方式的优势在于：协议明确了所有ViewModel必须遵守的规则，初始化逻辑集中统一，完全可以替代Java/Kotlin中抽象类的作用。

2. 依赖注入方案 #

如果你的网络层已经是通用实现，可以把具体的请求逻辑作为依赖注入到ViewModel中，而非通过子类硬编码URL：

class BaseViewModel<Response: Decodable> {
    private let fetchAction: () async throws -> Response
    
    // 注入请求闭包，闭包内部封装URL和网络请求细节
    init(fetchAction: @escaping () async throws -> Response) {
        self.fetchAction = fetchAction
    }
    
    func loadData() async throws -> Response {
        return try await fetchAction()
    }
}

// 使用时直接注入具体请求，甚至不需要子类
let userViewModel = BaseViewModel<User> {
    try await NetworkLayer.fetch(from: URL(string: "https://api.example.com/users")!)
}

// 当然也可以封装成子类
class UserViewModel: BaseViewModel<User> {
    init() {
        super.init(fetchAction: {
            try await NetworkLayer.fetch(from: URL(string: "https://api.example.com/users")!)
        })
    }
}

这种方式灵活性极高，能轻松适配不同的请求参数、请求方法，甚至替换网络层实现，非常适合复杂业务场景。

3. 协议关联类型+默认实现 #

如果需要更灵活的抽象，可以结合协议的关联类型和默认实现，把通用逻辑封装在协议扩展中：

protocol ViewModel {
    associatedtype Response: Decodable
    var requestURL: URL { get }
    func loadData() async throws -> Response
}

// 协议扩展提供通用实现，子类只需实现差异化部分
extension ViewModel {
    func loadData() async throws -> Response {
        return try await NetworkLayer.fetch(from: requestURL)
    }
}

// 子类只需指定响应类型和URL即可
class UserViewModel: ViewModel {
    typealias Response = User
    let requestURL: URL = URL(string: "https://api.example.com/users")!
}

这种模式完全模拟了抽象类的行为：协议定义抽象要求，扩展提供通用逻辑，子类只需要实现个性化配置，是Swift中实现抽象逻辑的经典方式。

三、总结 #

相比用convenience init传递URL，上述方案更符合Swift的编程范式：协议导向的方式清晰约束子类行为，依赖注入提升灵活性，都能更好地实现通用ViewModel与网络层的设计，替代Java/Kotlin中的abstract机制。

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