标签： module

在按照上一篇的做法将代码重构之后,发现虽然模块之间的依赖关系虽然明确了，
但是使用方式2的模块太多了， 方式2有一个弊端就是，对于模块间的引用没有天然的限制，如果不小心使用了某个模块却没有调用此模块的init函数，在某些情况下也是能够正常运行的。

因此我决定将除了log还要config这种几乎所有模块都会用到的模块使用方式2外，其他的模块全部使用方式1来实现。在实现之初我觉得除了那些最基础的模块外完全采用方式1来实现应该是一个完美的树形，但是在实现过程中发现将模块化的组织为一个完美的树形有着种种障碍，同层模块之间的交互几乎不可能全部在上层模块中解决，在这一个月中我一直在各种架构书籍中去寻找答案, 得到的结论竟然是想将代码写成完美树形是不可能的.

我甚至于找到两个很常见的例子来推翻可以将程序组成完美树形的依据, 一个公司的结构与一个PC机的结构:

公司的结构其实理论上来看是个完美树形, 老板下面有一堆经理, 每个经理下又有一堆组长. 但是仔细思考后就会发现, 如果有什么事, 老板肯定不会去了解所有细节而是让所有经理来开会, 换句话说, 老板几乎不可能先去与A经理商议再将得到的结果与B经理商议. 肯定是招集所有经理来开会, 那么经理之间就会有直接交互,这是不可避免的, 由于同层人员有交互那么其依赖关系就不可能形成一个完美的树形

PC机主要的三大件CPU, 硬盘, 内存的交互仔细想来也并非我所想象的完美树状依赖关系, 如果CPU想将硬盘的内容读到内存里去, 只是与硬盘发送读命令, 向内存发送写命令, 其数据传输是需要内存与硬盘的总线来进行的, 并不经过cpu, 这同样与我想象中的硬盘与内存所有交互是通过cpu来进行并不相符.

在上面的实例中我得出一个结论, 上层代码会控制其直属下层代码之间进行交互,但是并不是所有的交互细节都可以通过上层模块来进行(当然同层模块之间的交互不能够形成循环依赖)，在有些必要的情况下，两个同层模块间必须要留有接口用于交互。

经过不段斟酌，我认为代码模块之间的同层交互是这样的:
假设有三个模块module_a, module_b, module_c

module_a 属于上层模块, 其直属模块为module_b, module_c.
module_c与module_b处于同层, 但是有一个操作module_c 需要借助module_b来操作, 那么module_c的接口可能需要如下定义:


//module_c.h

struct module_c;
struct module_b;

struct module_c *module_c_create();
int module_c_free(struct module_c *m);

int module_c_do_something(struct module c *m, struct moduel_b *b, ...);

个人认为其实这种的同层模块间交互还是要尽量避免的, 如果两个模块之间有了接口依赖, 那么两个模块的耦合度就会增加, 其中一个模块就要对另一个块的接口有所了解, 对于维护和替换模块是不利的. 而如果去画依赖关系图的话, 也会增加一道依赖关系, 设计清晰度也会下降.

今天重新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只会被调用第一次.

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

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