代码依赖的2种情况

代码依赖有2种情况：

第一种是“静态依赖”，这种情况最常见。比如项目A依赖了Spring框架，那么只需要将Spring的jar包引入。每次只要编译A就可以，不需要每次先编译Spring的源码，然后再编译A（因为可以认为Spring是稳定的）

如果Spring升级了，那么项目需要引入新版本的jar包，然后重新编译一次。如果组件的API发生变化，造成项目编译失败，再调整受影响的代码即可

第二种是“动态依赖”，这种情况也很普遍。比如一个项目拆分成了2个工程，ProjectA和ProjectB，其中ProjectA是依赖ProjectB的

2个工程并行开发，那么这个时候A就不能依赖B编译得到的jar包，因为B也不稳定。如果A依赖3月1日的B编译得到的jar包，3月2日B删除了一个方法，那么由于A的依赖的jar包是旧的，无法感知这一变化，当A提交了代码之后，整个项目整体编译就失败了

这种情况下，应该将B设置为A的依赖工程，即A依赖B整个工程，而不是依赖B编译后得到的jar包。然后每次编译时，应该先编译B，再由B编译得到的jar包，对A进行编译

由此可见，当项目变得复杂之后，依赖关系和编译顺序，就会变成一个很头疼的问题（当项目团队规模大的时候，更是如此）。引入maven是一个很好的办法，可以降低依赖管理的复杂度

评论

1 楼 kyfxbl 2012-09-18  

补充：

回头想想，这种划分不一定是准确的

这2种依赖，其实本质上都是编译时的依赖，都是静态依赖。区别在于，一种是依赖“稳定”的jar包；另一种是依赖“不稳定”的代码，但是代码编译之后，依赖的仍然是jar包

所以这2种依赖，并没有本质上的区别，只是组织的问题