本文是系列文章《Maven 源码解析：依赖调解是如何实现的？》第七篇，也是最后一篇，主要做个总结。请按顺序阅读其他系列文章，系列文章总目录参见：hhttps://www.cnblogs.com/xiaoxi666/p/15583241.html。

总结

在本系列文章中，我们搭建了一个简单的多模块项目，以实验的形式，从源码角度解析了四种依赖调节原则。涉及到了传递依赖的两种调解原则、一种同文件内的覆盖原则，以及 dependencyManagement 依赖锁定原则。其中，传递依赖的两种调解原则涉及到 NearestConflictResolver 冲突调解器；而同文件内的覆盖原则最简单，就是简单的 Map 覆盖；最后，dependencyManagement 依赖锁定原则稍有些复杂，因为它涉及到了 dependencyManagement 的版本解析，并以解析出来的版本号为准。

在现实工作中，这几种依赖关系可能同时存在。尤其在大型工程中，dependencyManagement 版本锁定运用非常广泛，如果能从源码角度掌握其运行原理，一定会提升你对 Maven 的运用能力。

资源

本文中用到的源码已上传至 Github，地址：https://github.com/xiaoxi666/mavenDependencyDemo，需要的小伙伴请自行下载。

在阅读源码的过程中，我们学到了什么？

首先，我们了解了 Maven 依赖调解实现原理，以后面对各种输出信息，能够做到心中有数。稍微拓展一下，各种依赖管理工具的核心原理其实都差不多，无非就是管理各种依赖版本。希望本文能为你理解包管理工具的实现思路提供些许参考。

其次是设计方面的考量。Maven 提供了核心实现，并且预留了各种扩展点，可以让不同的插件实现不同的功能。这种开发模式可以非常方便功能扩展，对于一款软件的成长是很有利的。业界也有很多采用这种思路开发的产品，比如你熟悉的 Atom。

再说说算法，其实就是很经典的递归算法，以及常提到的备忘录（Map 存储已经解析过的依赖）。

最后，谈谈设计模式的体现。上面提到的源码就有几种，比如模板模式（不同冲突调解器的实现）、访问者模式（参照 visit 方法）、观察者模式（各种 Listener，事件产生时打印一些信息），以及桥接模式（dependency:tree 的实现其实是一个桥，类似于 slf4j 的模式）等等。

当然，你还学会了一种简单方便的 Maven 源码调试方法，哈哈。

参考

《Maven 实战》

Maven 官网：https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html