C语言中的封装 - 答读者问

写C代码的时候，最头疼的事情是哪些信息要暴露给外界，哪些隐藏在模块自身。如果不能处理好封装，那么久而久之，代码就自然演进成互相缠绕的意大利面条。

比如说在一个ring buffer的基础上实现一个queue，我们可以提供 queue.h 暴露该模块的api，queue.c 进行具体实现，最基本的想法必然是：

queue.h

typedef struct {
    ring_buffer_t *ring;
    ...
    uint64_t counters[MAX_COUNTERS];
} queue_t;

int enqueue(queue_t *q, buf_t *buf);
buf_t *dequeue(queue_t *q);

然后在 queue.c 里面具体实现enqueue/dequeue。

这样做的坏处是，queue实现的细节被暴露给了调用者，只要调用者拿到了queue的pointer，就可以操作里面的ring，counters等等。如果queue模块本身没有提供充分的api，比如获取某个counter的信息，那么调用者可能就会图省事，自行做类似 q->counters[COUNTER_A] 这样的事情，从而完全破坏了模块的内聚。

更好的做法是使用 typedef 对类型做延迟定义。如下所示：

queue.h

typedef struct queue_s queue_t;

int enqueue(queue_t *q, buf_t *buf);
buf_t *dequeue(queue_t *q);

然后在 queue.c 里，真正去定义 struct queue_s：

#include "queue.h"

struct queue_s {
    ring_buffer_t *ring;
    ...
    uint64_t counters[MAX_COUNTERS];  
}

这样，当你在该模块外的地方即使拿到了queue的pointer，也无法进行 q->counters[COUNTER_A] 这样的操作，编译器会报错：

error: dereferencing pointer to incomplete type

一开始使用这种方法定义数据结构会让自己或者别人写代码的时候很不舒服，因为拿到了一个pointer，却无法访问其内部的数据，是一种「很不C」的做法。这样会逼迫你写更多的代码，在需求不断变化（增加）的时候封装出来更多的api。而更多的api意味着更多的重构，以及更通盘地考虑设计上的优化。最终，模块的内聚大大加强，任何外部代码只能通过模块提供的api进行受限的操作，无法再像之前那样随心所欲了。