HarmonyOS Next架构实战：抽象类与接口的协作之道

还记得第一次设计设备驱动框架时，面对多设备适配的混乱代码，直到用抽象类和接口重构后才豁然开朗。这套架构方案在智能家居项目中经受住了10+设备类型的考验，今天分享其中的核心设计思路。

一、抽象与接口的协作哲学

1.1 核心差异对比（实战视角）

特性	抽象类	接口
定位	算法骨架（带部分实现）	能力契约（纯行为定义）
使用场景	数据处理流程标准化	跨模块能力抽象
典型案例	日志框架基础实现	通信协议定义

协作黄金法则：

• 接口定义"能做什么"，抽象类实现"部分怎么做"
• 子类继承抽象类并实现接口，组合复用双重优势

二、模板方法与契约组合实战

2.1 日志系统的分层设计

// 定义日志接口（契约）
interface LogContract {
    func log(msg: String)
    func logError(msg: String)
}

// 抽象类实现公共逻辑
abstract class BaseLogger <: LogContract {
    // 模板方法：统一日志格式
    public func log(msg: String) {
        let time = getFormattedTime()
        appendLog("[\(time)] \(msg)") // 抽象方法由子类实现
    }
    
    public func logError(msg: String) {
        log(msg: "[ERROR] \(msg)") // 复用普通日志逻辑
    }
    
    protected abstract func appendLog(formattedMsg: String)
    private func getFormattedTime() -> String { /* 通用时间格式化 */ }
}

// 具体实现类（文件日志）
class FileLogger <: BaseLogger {
    private var fileHandler: FileHandler
    
    protected override func appendLog(formattedMsg: String) {
        fileHandler.write(formattedMsg)
    }
}

关键优势：

• 接口统一日志行为，抽象类封装时间格式化等公共逻辑
• 子类仅需实现差异化存储逻辑，代码量减少40%

三、多接口整合：设备驱动框架设计

3.1 跨设备控制的弹性架构

// 定义设备控制接口
interface Controlable {
    func powerOn()
    func powerOff()
}

// 定义状态上报接口
interface Reportable {
    func getStatus() -> String
}

// 抽象类整合双重能力
abstract class DeviceDriver <: Controlable, Reportable {
    // 开机模板方法
    public func powerOn() {
        checkPermission()     // 通用权限检查
        doPowerOn()           // 抽象：子类实现具体开机逻辑
        logStatus()           // 通用状态记录
    }
    
    public func getStatus() -> String { /* 通用状态格式 */ }
    protected abstract func doPowerOn()
    private func checkPermission() { /* 通用权限逻辑 */ }
}

// WiFi模块驱动实现
class WiFiDriver <: DeviceDriver {
    protected override func doPowerOn() {
        // WiFi芯片初始化逻辑
        println("WiFi模块已启动")
    }
}

3.2 接口冲突处理实战

interface A { func action() }
interface B { func action() }

// 抽象类统一冲突处理
abstract class ConflictHandler <: A, B {
    public func action() {
        // 统一预处理逻辑
        handleAction() // 抽象方法由子类实现
    }
    protected abstract func handleAction()
}

四、架构优化的血泪经验

4.1 驱动框架演进之路

初版问题：

• 直接实现接口导致重复代码多
• 新增设备类型时需修改多处逻辑

重构方案：

1. 抽象类封装通用流程（权限检查、日志记录）
2. 接口定义核心能力（控制、上报）
3. 子类仅实现设备特有的硬件操作

优化效果：

• 新增设备开发时间从2天缩短到4小时
• 代码维护成本降低60%

4.2 抽象类设计三原则

1. 单一职责：每个抽象类专注1个核心流程（如日志、设备控制）
2. 钩子优先：用抽象方法暴露扩展点，而非继承后覆盖整个流程
3. 终结器设计：

abstract class ResourceDriver {
    public abstract func release()
    ~init() { release() } // 确保资源释放
}

五、高阶应用：插件化架构实践

5.1 插件接口与抽象类组合

// 插件基础接口
interface Plugin {
    func init(params: Any) -> Bool
    func execute() -> Any
}

// 插件抽象类（实现公共逻辑）
abstract class BasePlugin <: Plugin {
    public func init(params: Any) -> Bool {
        // 通用初始化检查
        return doInit(params)
    }
    
    protected abstract func doInit(params: Any) -> Bool
    public abstract func execute() -> Any
}

// 网络插件实现
class NetworkPlugin <: BasePlugin {
    protected override func doInit(params: Any) -> Bool {
        // 网络插件特有初始化
    }
    
    public func execute() -> Any { /* 网络请求逻辑 */ }
}

插件化优势：

• 支持运行时动态加载插件
• 新增功能无需修改主框架代码

六、避坑指南：从踩坑到填坑

1. 接口膨胀陷阱：
   超过5个方法的接口考虑拆分为多个专用接口

2. 抽象类过度设计：
   抽象方法控制在3个以内，否则拆分为多层抽象类

3. 类型转换风险：
   用类型擦除或泛型约束减少强制类型转换