如何不让代码演进成互相缠绕的意大利面条？

如何处理好封装，

不让代码演进成互相缠绕的意大利面条？

对使用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进行受限的操作，无法再像之前那样随心所欲了。这也正是面向对象的编程的基本思想。

有的人说，

“C语言是面向过程编程的语言，C++是面向对象编程的语言。”

其实，这种说法并不贴切。通过上面的例子大家可以看到，通过库的封装和相应的编程方法，C语言一样可以实现相应的函数封装，达到面向对象的设计模式。

说到底，各种各样的编程语言到头来只是一种工具，并没有明显的根本区别。作为一个好的程序员，关键还是要培养自己的编程思想、丰富软件设计模式，这样才能更淡定地面对未来日新月异的软件技术发展潮流。

另外，在上文中还提及到了API的设计模式。在现在的软件工程中，API接口及标准化可以说是非常重要的一个部分，在接下来的文章里我将会继续对API设计及架构进行更多的解读与分享，敬请期待。

接下来的文章里我将会继续对API设计及架构进行更多的解读与分享，敬请期待。

继续阅读更多实力技术干货

文章内容为睿江云睿普云博士原创，欢迎转载请注明出处

http://mp.weixin.qq.com/s/GA5tLxNWtuL6PBRnOcpinQ

持续关注我们的微信公众号“睿普Eflypro”和技术博客！