浅谈 C 语言中模块化设计的范式
今天继续谈模块化的问题。这个想慢慢写成个系列，但是不一定连续写。基本是想起来了，就整理点思路出来。主要还是为以后集中整理做点铺垫。
我们都知道，层次分明的代码最容易维护。你可以轻易的换掉某个层次上的某个模块，而不用担心对整个系统造成很大的副作用。
层次不清的设计中，最糟糕的一种是模块循环依赖。即，分不清两个模块谁在上，谁在下。这个时候，最容易牵扯不清，其结果往往是把两者看做一体去维护算了。这里面还涉及一些初始化次序等繁杂的细节。
其次，就是越层的模块联系。当模块 A 是模块 B 的上层，而模块 B 又是模块 C 的上层，这个时候，让模块 C 对模块 A 可见，在模块 A 中有对 C 导出接口的直接调用，对于清晰的设计是很忌讳的一件事。虽然，我们很难完全避免这个问题，去让 A 对 C 的调用完全通过 B 。但通常应尽力为之。（注：以后写书的话，我争取补充一些实际的例子来说明）不过，对语言不原生支持的数据类型，以及基础设施，但却有必要创造出来给系统用的。可以有些例外。比如内存管理，log 管理，字符串（C 语言用原始库函数管理比较麻烦）等等，我们可能以基础模块的形式提供。但却可能被不同层次的模块直接使用。但，上到一定层次后，还是需要去隐藏它们的。
下面来一点更实际的分析。
以 C 语言为例，由于 C 语言缺乏 namespace 的原生支持，我们通常给 api 加上统一前缀来区分。这倒也不麻烦。
那么模块 A 看起来就是一堆 'A_xxxxx' 为名字的方法。我个人主张单个模块不宜过大，在实现时适合放在同一个 .c 文件里即可。通常，一个模块会围绕一类对象处理。这些对象可以用整数 handle 来表示，也可以用一个特定类型的对象指针。两种方案各有千秋。先来谈对象指针的方案。
一个模块 A 的接口描述文件很可以是这样的（希望以后能补上更现实的代码）:
1 #ifndef _A_h 2 #define _A_h 3 4 struct A; 5 struct B; 6 7 struct A* A_create(void); 8 void A_release(struct A *self); 9 void A_bind(struct A *self , struct B *b); 10 void A_commit(struct A *self); 11 void A_update(void); 12 13 int A_init(void); 14 15 #endif
这里，我们定义了 A 这种数据类型。我个人反对用 typedef 或宏来减少代码输入。除非有特别的理由，都写上 struct 前缀，而不是定义出新类型。尤其是在较底层的模块设计时更是如此。在接口描述时，struct A 的细节是绝对不应该暴露出来的，它的数据结构应该仅存在于实现的文件 a.c 中。
关于 A 的接口通常分两类，一类是对 struct A* 做一些处理的，那么就让第一个参数传入 self 指针。这相当于 C++ 的 this 指针。比如上例中的 A_commit ；另一类接近于 C++ 类的静态成员函数，通常用于对这一类对象全部做一个处理，如 A_update 。
注：我无意用 C 去模拟 C++ ，但基于一类数据类型做一些处理的方法，对于 C ，这样的写法也是一个常规的范式而已。至于面向对象等在构建复杂系统时常用到的方法，以后我会谈谈我自己常用的另一些范式。或许像 C++ ，也可以不像。怎么写更好，是个见任见智的问题。不用过于拘泥。
这里的例子中，我们还提到了另一个数据类型 B 。显然，它是放在 B 模块中的。
我们通常不会在 a.h 中去 include b.h ，而只是声明一下 struct B 。（对于 C 语言来说，这并不必要，但写上是个好习惯）。这是因为，如果 B 是位于 A 之下的模块，既在 A 模块的实现中，会用到 B 的方法，我们通常不会让用到 A 模块的人，可以看见 B 的接口。包含 a.h 的同时隐式包含 b.h 就是不必要的了。
从范例代码中，我们可以猜想，struct A 是对 struct B 的某种封装，可以通过对 A 的操作，间接操作到其中的 B 类型。在 A 的模块初始化 A_init 中一定就会初始化 B 了。如果是这样，B 的层次就位于 A 之下。
往往 struct B 中还会保留一个 struct A 类型的引用。首先，我们应该尽力避免这种情况。即：位于下层的 B 应该对上层的 A 一无所知是最好的。如果在 B 模块中必须出现 struct A，那么我们应该至少保证，仅仅是 struct A * ，一个引用，而绝对不能出现任何对 A 模块内接口的调用。不要认为使用巧妙的方法，绕过循环依赖初始化问题就够了。这应该是一个设计原则，不要去违反。
btw, 草率的接口设计往往是日后系统脆弱的根源。图一时之快，随意暴露一些接口，或是自以为聪明的用一些“巧妙”的方法，甚至是语法糖来绕过设计原则，都是很危险的。
一个常见的难处理的问题是：如果 struct A 和 struct B 相互有双向引用。怎样建立这个引用关系？这个建立的过程，到底是 A 的方法，还是 B 的方法？我的答案是，谁在上层，就是谁的方法。
但是 A 和 B 相互都看不见内部数据布局的细节，让 B 的内部对 A 类型做一个引用，比如也需要从 B 模块中暴露一个接口出来。这个接口，可能仅供 A 使用。在这个例子里，就是仅供 A_bind 这个方法去使用。
如果是 C++ ，我们或许会采用 friend 。也可能使用其它一些技巧。反正 C++ 里可以挖掘的语法太多了。但 C 怎么办？下面给个我自己的方案。
原本，我们在 B 中导出的 api 是这样的：
void B_set_A(struct B *self,struct A * a);
现在写成：
struct i_A; void B_set_A(struct B *self,struct i_A *a);
在 b.c 的实现中，加一个函数用于 struct i_A * 到 struct A * 的转换。
static inline struct A * A(struct i_A *a) { return (struct A *)a; }
然后在 a.c 的实现中，加一个类似函数用于转换 struct A * 到 struct i_A * 。
这样，在 a.c 之外，其它模块因为不能得到任何 struct i_A 类型，而不会错误的使用 B_set_A 这个接口了。
原文链接：http://blog.codingnow.com/2010/01/modularization_in_c_1.html
