讨论个有关模块化设计的问题

## 场景: 在golang,现在的程序中有两个模块,于是创建了package A 和 package B。 由于业务逻辑的特殊性,B中有一个子模块C,C中有一个子模块D,D模块的初始化/构造函数依赖于外部的A模块中的一个值。除此之外, B包中的任何方法、属性 都与A包无任何关联。 B模块的初始化过程中会初始化子模块C,C模块的初始化过程中会初始化子模块D。 ## 问题: 基于以上的情况 - 该如何设计当前的模块结构才是最合适的呢? - 鉴于模块化“高内聚低耦合”的设计原则,A和B两个模块 除了 子模块D依赖A中的一个值这一点之外,没有任何交集 - 如果把A和B完全打通搞成同一个模块,违背了高内聚的原则,而目前的A B分开的模块结构,又存在业务逻辑上的这种特殊依赖,产生了让人不太舒服的耦合度 - 场景只是就事论事举个例子,真实的业务场景中肯定不止ABCD这四个模块,B中还会有很多其他的子模块,A中亦然,所以大家没必要纠结我的场景为什么把四个模块要搞出这种奇怪的模块结构,我相信这样的情景在很多业务场景中都存在。 ## 补充: 我们暂且称D所依赖的那个值为x, x需要依赖于A模块中某个方法的执行结果,也就是说 正常情况下任何程序模块想拿到x值,需要先实例化A,然后调用A.GetXValue()方法获取。 不仅如此,在D模块中,依赖x的方法可能是一个私有方法,也就是golang中小写字母开头的签名方法。这样一来,可能有好几个方法会因为x这一个值的依赖被强迫强耦合起来。
已邀请:
为什么不能传参呢?

h12 - https://h12.io/about

1. package (P) 和subpackage (S) 只是S的路径前缀是P,这和引用关系是独立的。可以P引用S,或者S引用P,或者互相没有引用关系(比如共同引用另一个包,又比如共同被另一个包引用)。
2. 包之间不支持直接或间接的循环引用

考虑到以上两点,每当发现A,B两个包需要互相引用时,两个选择:
1. 合并A,B
2. 提取共同的类型到C,然后A,B分别引用C

至于A,B的路径是否需要为对方的前缀,当作命名问题来考虑,和逻辑关系无关。
由于这里并没有循环引用存在,那么子模块D 依赖外部模块A 的值并不一定是个问题。
关键还要看模块A,B 的架构层次。
1,若A 处于架构底层,是基础模块。则B 引用A 本身没什么问题。
2,反之,则B 直接引用A 是有问题的。
D模块初始化/构造函数 会引用A模块的一个经过一系列初始化之后的变量. 听起来就不太合理.
通过参数把A的变量传入D的构造函数难道不行吗?

要回复问题请先登录注册