在按照上一篇的做法将代码重构之后,发现虽然模块之间的依赖关系虽然明确了,
但是使用方式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, ...);

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