模块的封装之C语言类的封装

---

[微知识]模块的封装（一）：C语言类的封装

---

　　

　　是的，你没有看错，我们要讨论的是C语言而不是C++语言中类的封装。在展开知识点之前，我首先要

重申两点：

　　1、面向对象是一种思想，基本与所用的语言是无关的。当你心怀面向对象时，即使使用QBasic也能写

　　　　出符合面向对象思想的代码，更不要说C语言了。举一个反例，很多人初学C++的时候，并没有掌

　　　　握面向对象的思想，活生生的把类当结构体来使用的也不在少数吧。

　　2、面向对象的最基本的出发点是“将数据以及处理数据的方法封装在一起”，至于继承、派生、多态之类

　　　　的则是后面扩展的东西。在C语言中，如果用结构体来保存数据，并将处理这些数据的函数与结构体

　　　　的定义封装在同一个.c文件中，则该.c文件就可以视作一个类。如果将指向具体函数的函数指针与结

　　　　构体的其他成员封装在同一个结构体中，则该“对象”的使用甚至与C++相差无几了。

　　

　　以上的内容是面向对象的C语言（Object-Oriented C Programming with ANSI-C）技术的基本出发

点。作为引子，在使用OOC技术的时候，我们会遇到这么一个问题：是的，我们可以用结构体模拟类，将所

有的成员变量都放在结构体中，并将这一结构体放在类模块的接口头文件中，但是问题是结构体里的成员变量

都是public的，如何保护他们使其拥有private的属性呢？解决的方法就是掩码结构体（Masked Structure）

　　那么什么是掩码结构体呢？在回答这个问题前，我们先看下面的例子。已知我们定义了一下用于在C语言

里面进行类封装的宏，如下所示：

 #define EXTERN_CLASS(__NAME,...) \
     typedef union __NAME __NAME;\
     __VA_ARGS__\
     union __NAME {\
         uint_fast8_t chMask[(sizeof(struct {

 #define END_EXTERN_CLASS(__NAME) \
         }) + sizeof(uint_fast8_t) - ) / sizeof(uint_fast8_t)];\
     };

 #define DEF_CLASS(__NAME,...)\
     typedef union __NAME __NAME;\
     __VA_ARGS__\
     typedef struct __##__NAME __##__NAME;\
     struct __##__NAME{

 #define END_DEF_CLASS(__NAME) \
     };\
     union __NAME {\
         uint_fast8_t chMask[(sizeof(__##__NAME) + sizeof(uint_fast8_t) - ) / sizeof(uint_fast8_t)];\
     };

 #define CLASS(__NAME)               __##__NAME

假设我要封装一个基于字节的队列类，不妨叫做Queue，因此我们建立了一个类文件queue.c和对应的接口头文件

queue.h。假设我们约定queue.c不包含queue.h（这么做的好处很多，在以后的内容里在讲解当然对掩码结构体

的技术来说，模块的实现是否包含模块的接口头文件并不是关键）。

我们首先想到是定义一个类来表示队列，他的一个可能的形式如下：

 //! \name byte queue
 //! @{
 typedef struct {
     uint8_t *pchBuffer;    //!< queue buffer
     uint16_t hwBufferSize; //!< buffer size
     uint16_t hwHead;       //!< head pointer
     uint16_t hwTail;       //!< tail pointer
     uint16_t hwCounter;    //!< byte counter
 }queue_t;
 //! @}

目前为止一起都还OK，由于quue.c文件不包含queue.h，因此我们决定在两个文件中各放一个定义。由于.h文件包含了

数据队列的完整信息，使用该模块的人可能会因为种种原因直接访问甚至修改队列结构体中 的数据------也行在这个例子

中不是那么明显，但是在你某个其他应用模块的例子中，你放在结构体里面的某个信息可能对模块的使用者来说，直接操作

更为便利，因此悲剧发生了----原本你假设“所有操作都应该由queue.c来完成”的格局打破了，使用者可以轻而易举的修改

和访问结构体的内容-------而这些内容在面向对象的思想中原本应该是私有的，无法访问的（private）。原本测试完好的

系统，因为这种出乎意料的外界干涉而导致不稳定，甚至crash了。当你气冲冲的找到这么“非法”访问你结构体的人时，对方

居然推了推眼镜，一脸无辜的看着你说“根据接口的最小信息公开原则，难道你放在头文件里面的信息不是大家可以放心使用

的么？”

OTZ。。。。垭口无言，然后你会隐约觉得太阳穴微微的在跳动。。。

且慢，如果我们通过一开始提供的宏分别对queue.h和queue.c中的定义改写一番，也许就是另外一个局面了：

queue.h

 ...
 //! \name byte queue
 //! @{
 EXTERN_CLASS(queue_t)
     uint8_t *pchBuffer;    //!< queue buffer
     uint16_t hwBufferSize; //!< buffer size
     uint16_t hwHead;       //!< head pointer
     uint16_t hwTail;       //!< tail pointer
     uint16_t hwCounter;    //!< byte counter
 END_EXTERN_CLASS(queue_t)
 //! @}
 ...
 extern bool queue_init(queue_t *ptQueue, uint8_t *pchBuffer, uint16_t hwSize);
 extern bool enqueue(queue_t *ptQueue, uint8_t chByte);
 extern bool dequeue(queue_t *ptQueue, uint8_t *pchByte);
 extern bool is_queue_empty(queue_t *ptQueue);
 ...

queue.c

 ...
 //! \name byte queue
 //! @{
 EXTERN_CLASS(queue_t)
     uint8_t *pchBuffer;    //!< queue buffer
     uint16_t hwBufferSize; //!< buffer size
     uint16_t hwHead;       //!< head pointer
     uint16_t hwTail;       //!< tail pointer
     uint16_t hwCounter;    //!< byte counter
 END_EXTERN_CLASS(queue_t)
 //! @}
 ...
 extern bool queue_init(queue_t *ptQueue, uint8_t *pchBuffer, uint16_t hwSize);
 extern bool enqueue(queue_t *ptQueue, uint8_t chByte);
 extern bool dequeue(queue_t *ptQueue, uint8_t *pchByte);
 extern bool is_queue_empty(queue_t *ptQueue);
 ...

对照前面的宏，我们实际上可以手工将上面的内容展开，可以看到实际上类型queue_t是一个掩码结构体，

里面只有一个起到掩码作业的数组chMask，其大小和真正后台的类型_queue_t相同-----这就是掩码结

构体结构体实现私有成员保护的秘密。解决了私有成员的保护问题，剩下还有一个问题，对于queue.c的

函数来说queue_t只是一个数组，那么正常的功能如何实现呢？下面的代码片段为你解释一切：

 ...
 bool is_queue_empty(queue_t *ptQueue)
 {
     CLASS(queue_t) *ptQ = (CLASS(queue_t) *)ptQueue;
     if (NULL == ptQueue) {
         return true;
     }
     return ((ptQ->hwHead == ptQ->hwTail) && ( == ptQ->Counter));
 }
 ...

从编译器的角度来讲，这种从queue_t到_queue_t类型的转换是逻辑上的，并不会因此产生额外的代码，

简而言之，使用掩码结构体几乎是没有代价的----如果你找出了所谓的代价，一方面不妨告诉我，另一方

面不妨考虑这个代价和模块的封装相比是否是可以接受的。