3、组件化编程实战：如何将一个LED驱动从业务逻辑中剥离，形成独立组件

好，咱们直接进入正题。

前面两章讲了理论，这一章咱们来点实在的。我见过太多项目，LED闪烁的代码散落在主循环的各个角落，跟按键检测、串口打印、传感器读取搅在一起。改个闪烁频率，得翻遍整个main.c。这种写法，说白了就是“能跑就行”，但后期维护起来，那叫一个痛苦。

今天我们就拿一个最简单的LED驱动开刀，手把手把它从业务逻辑里拆出来，做成一个高内聚、低耦合的独立组件。你想想看，连LED都能拆干净，其他复杂外设自然不在话下。

3.1 为什么LED驱动也需要“架构”？

有人可能会问：“一个LED而已，不就是GPIO拉高拉低吗？至于搞这么复杂？”

嗯，这个问题我当年也问过自己。直到有一次，我在一个项目里需要同时支持三款不同型号的LED——普通GPIO、PWM调光、还有一颗带I2C接口的RGB灯。如果每个都写死在业务逻辑里，那代码简直没法看。

组件化的核心目的就三个：

• 可替换：换一种LED硬件，业务代码不用改。
• 可测试：单独测试LED驱动，不用搭整个系统。
• 可复用：下一个项目直接复制这个组件，改两行配置就行。

3.2 第一步：定义组件接口

拆组件的第一步，不是写代码，而是画边界。你得先想清楚：这个组件对外提供什么服务？

我个人习惯，先定义一个抽象接口。在C语言里，就是用结构体封装函数指针。

/* led_interface.h */
#ifndef _LED_INTERFACE_H_
#define _LED_INTERFACE_H_

#include <stdint.h>

typedef struct {
    void (*init)(void);
    void (*on)(void);
    void (*off)(void);
    void (*toggle)(void);
    void (*set_brightness)(uint8_t percent);
} led_ops_t;

#endif /* _LED_INTERFACE_H_ */

看到没？这个接口里没有任何硬件细节。它只定义了五个操作：初始化、开、关、翻转、调亮度。至于背后是GPIO还是PWM，调用者完全不需要知道。

3.3 第二步：实现具体驱动

接口定义好了，接下来就是实现。我们以最普通的GPIO驱动为例。

/* led_gpio.c */
#include "led_interface.h"
#include "bsp_gpio.h"  /* 假设这是板级支持包 */

static void gpio_init(void) {
    bsp_gpio_init(LED_PIN, GPIO_MODE_OUTPUT);
    bsp_gpio_write(LED_PIN, 0);
}

static void gpio_on(void) {
    bsp_gpio_write(LED_PIN, 1);
}

static void gpio_off(void) {
    bsp_gpio_write(LED_PIN, 0);
}

static void gpio_toggle(void) {
    bsp_gpio_toggle(LED_PIN);
}

static void gpio_set_brightness(uint8_t percent) {
    /* GPIO不支持调光，直接忽略或报错 */
    (void)percent;
}

/* 暴露给外部的操作句柄 */
const led_ops_t led_gpio_ops = {
    .init = gpio_init,
    .on = gpio_on,
    .off = gpio_off,
    .toggle = gpio_toggle,
    .set_brightness = gpio_set_brightness
};

这里有个细节：set_brightness在GPIO驱动里是个空操作。但接口里必须有它，因为上层业务可能统一调用。这就是“接口隔离”的体现——你不需要的功能，给个空实现就行，但不能让上层代码去判断“这个LED能不能调光”。

3.4 第三步：业务逻辑只认接口

现在，业务代码长什么样？

/* app_led_control.c */
#include "led_interface.h"

/* 外部传入的操作句柄 */
static const led_ops_t *s_led = NULL;

void app_led_init(const led_ops_t *ops) {
    s_led = ops;
    if (s_led && s_led->init) {
        s_led->init();
    }
}

void app_led_blink(uint32_t interval_ms) {
    if (!s_led || !s_led->toggle) return;
    /* 假设这是一个定时器回调 */
    s_led->toggle();
}

void app_led_emergency(void) {
    if (!s_led || !s_led->on) return;
    s_led->on();
}

你看，业务代码里完全没有GPIO、PIN、寄存器这些词。它只调用s_led->on()。至于这个on背后是拉高电平还是发送I2C命令，业务逻辑一概不管。

3.5 第四步：组装与配置

最后一步，就是在系统初始化时，把具体的驱动“注入”到业务逻辑里。

/* main.c */
#include "app_led_control.h"
#include "led_gpio.h"   /* 包含 led_gpio_ops */
/* 如果换PWM驱动，就改成 #include "led_pwm.h" */

int main(void) {
    /* 系统初始化... */
    
    /* 注入GPIO驱动 */
    app_led_init(&led_gpio_ops);
    
    /* 如果想换PWM驱动，只需改这一行：
       app_led_init(&led_pwm_ops); */
    
    while(1) {
        app_led_blink(500);
        /* 其他业务... */
    }
}

这就是依赖注入的雏形。业务逻辑不负责创建驱动，只负责使用驱动。驱动怎么来？由上层（main函数）传进来。

3.6 组件关系图

下面这张图，把整个组件化结构画清楚了。你可以看到，业务逻辑和硬件驱动之间，隔着一层抽象的接口。

3.7 组件化带来的好处

拆完之后，效果立竿见影。我整理了一个对比表格，你看看差别有多大。

对比维度	传统写法（耦合）	组件化写法（解耦）
代码修改	改LED硬件，业务代码要跟着改	只改驱动文件，业务代码不动
测试难度	必须烧录到板子上才能测	可以写Mock驱动，在PC上测
复用性	每个项目都要重写一遍	复制驱动文件，改配置即可
团队协作	多人改同一个文件，冲突频繁	各改各的驱动，接口不变就行
代码可读性	业务逻辑里全是寄存器操作	业务逻辑清晰，像读文章

3.8 避坑指南

最后，分享几个我踩过的坑，希望能帮你少走弯路。

• 接口不要过度设计：我曾经给LED接口加了get_status()、set_color()、set_flash_pattern()，结果大部分实现都是空函数。接口够用就好，别贪多。
• 注意初始化顺序：驱动初始化之前，业务代码不能调用任何接口。我习惯在app_led_init()里做一次完整的初始化，而不是让业务代码自己去调init。
• 空指针保护是底线：所有接口函数里，第一行就检查s_led和函数指针是否为空。别问我为什么强调这个——问就是吃过亏。
• 驱动文件要独立：每个驱动一个.c和一个.h，不要把所有驱动塞到一个文件里。否则就失去了组件化的意义。