跟我学代码架构设计模式之--独特的视角分析程序模块依赖关系

# 当前几乎所有的程序都是按照模块化的思想设计的,比如java的一个jar可以看做一个独立的模块,nodejs的一个带有package描述文件的包可以看做一个模块,linux的一个so库可以看做一个模块,windows的dll可以看做模块。

# 一个程序一般是由一个主模块,若干个被依赖的模块做为一个完整的程序(递归边界思想)。其中被依赖的模块也可能会有本身依赖的其他模块,最终一个完整的程序可以看做由一个主模块为树根、依赖模块为下级节点的模块依赖树。

# 模块最终由宿主程序,即模块加载器加载执行,比如jvm的classloader、nodejs的require函数、linux的动态连接器程序。

# 当前程序界普遍把程序依赖关系分成 扁平依赖 和 嵌套依赖,即:

扁平依赖是把程序的主模块所依赖的所有模块都放在一个子目录下存放,不再用多级目录的形式区分子模块间的依赖关系,典型的代表有JAVA程序。

嵌套依赖是把主模块的所有依赖按模块间的依赖关系建立多级子目录分层存放,典型的代表有nodejs程序。

# 我认为上面的这种分类不太好,这里给出我独特的划分思想--逻辑依赖 和 物理依赖!

逻辑依赖:

很简单的思想,依赖就是依赖,逻辑上的依赖就是原样体现一个模块和其依赖的模块的树型关系,不管模块的版本,即使模块依赖树中会有不同模块依赖另外的同一模块的不同版本的情况!

物理依赖:

我的定义是完整的程序最终发布执行时,所有的依赖模块在物理磁盘上的组织方式!这个组织方式可以按目录层次的划分分为扁平依赖存储方式和嵌套依赖存储方式。

具体选择何种物理依赖组织方式是和宿主模块加载器的特性紧密相关的,但是有一点可以确定的是:大部分程序实现的模块加载器都可以按照一定的规则通过目录树遍历的方式加载物理磁盘上的模块,有的可能是从主模块依赖目录的树根开始深度遍历查找子依赖模块,有的可能是从依赖目录的当前目录开始向父目录回溯的方式遍历查找依赖模块。如nodejs的require加载modules目录、java的classloader加载classpath下的jar。所以我们可以得出的一点结论是:物理依赖按扁平目录存放和嵌套目录存放其实都是OK的,但是最好如何存放?实际上和宿主加载器是否允许重复加载同一模块有关,请看下面的分析:

1 jvm的classloader要求同一classloader下的同一种jar包(包名和类名完全相同,但是版本号不同的jar包为同一种jar包)只能有一份(即一个版本)jar加载到内存中执行。这种情况,物理依赖中的模块是不允许有重复模块的,而一个目录存放所有依赖的扁平依赖物理存放方式正好能避免重复模块名的模块!所以java程序在发布的时候一般都是一个lib下存放所有的jar包!

2 nodejs本身是给予chrome的v8 js引擎,是允许不同版本的同一模块按需加载的,所以nodejs的程序模块即可以按扁平存放方式存放也可以按嵌套存放方式存放!

(完)

发布了63 篇原创文章 · 获赞 25 · 访问量 8万+

猜你喜欢

转载自blog.csdn.net/w1857518575/article/details/85331799