代码模块化(一)

今天重新review了一遍代码, 发现模块竟然有几十个之多, 之间引用大概如下:

MODULE_MAIN -> MODULE_A MODULE_B MODULE_C …
MODULE_A -> MODULE_B MODULE_C MODULE_SUB_A1 MODULE_SUB_A2 …
MODULE_B -> MODULE_SUB_B1 MODULE_SUB_B2 …
MODULE_C -> MODULE_SUB_C1 MODULE_SUB_C2 …
…

也就是说这些模块之间其实并非是同级的, 有些模块只是被某一个上层模块调用罢了.
但是我目前代码里面其实并不能很明显的看到这种引用关系, 如果这种模块多了, 相互间的引用关系在大脑中就容易出现混乱(最起码我是这样), 而且不容易维护.

因此必须要尽最大可能明确这种依赖关系, 并加以限制以使模块之间的依赖不会循环不会交错.

我一般是一个C文件来当做一个模块, 如果一个C文件过长就会将此C文件拆成几个子模块.

总结一下目前我使用的模块创建方式:
//方式1
struct module;
struct module *module_create(…);
int module_do_something(struct module *self, …);

int module_free(struct module *self);
//方式2
int module_init(…);
int module_do_something(…);

方式1由于整个module相当于存在于self所指向的内存区域, 以上面的引用关系来看MODULE_SUB_A1之类的模块很适合采用方式1来编写, 因为此模块只是为更好的完成MODULE_A, 那么也只有MODULE_A才能来使用, 如果使用了方式1, module_create返回的self就只有MODULE_A才能拥有, 就不用担心被其他模块引用, 或错误的引用.

在写代码时应该很少会遇到所有模块只会被引用一次, 一定有些模块用来当作基础模块来使用, 如上面的MODULE_B, MODULE_C这种即被MODULE_MAIN引用又被MODULE_A引用, 那么此时MODULE_B, MODULE_C再使用方式1来实现就势必会出现全局变量了, 全局变量的出现会使程序变得更糟糕, 这时就必须使用方式2了.

但是为了让方式2也能清晰表示出依赖关系, 可以稍加限制来清晰表明模块引用关系, 示例代码如下:

module_a 引用 module_b
module_c 引用 module_b

int module_a_init()
{
….
module_b_init();

return xx;
}

int module_c_init()
{
…..
module_b_init();

return xx;
}

如果每个模块都遵循这种规则, 那很就可以很清晰的看出模块之间的依赖关系. 这时会出现一个问题就是module_b_init可能会被多次调用的问题. 可以在自己模块数据中记是否被init的过来实现, 也可以通过实现一个module_init_once(int (*init)(void))函数来间接调用module_b_init, module_init_once来保证module_b_init只会被调用第一次.

————————————
最近越来越觉得其实代码模块组织应该是树形的.

注:部分灵感来自云风大神