对依赖关系的深入理解

在编程中，依赖关系随处可见，从类与类的依赖关系到模块与模块的依赖关系、应用与应用的依赖关系、操作系统与驱动程序的依赖关系，可以说依赖关系是编程中的一个主要属性。那么依赖究竟意味着什么呢？

假如A依赖于B，那么就代表A不能离开B，A会用到B的功能，A知道B的存在。A为什么要去依赖B呢？有什么好处呢？很显然，

好处是A可以使用B的功能。

但随之而来的副作用是B一旦发生改变，A也得跟着改变。这样一来，A的稳定性和灵活性就会下降，要解决这一点，就要使用控制反转，此时的做法是。

在A中声明要使用的功能的抽象，然后在B中实现该抽象。结果就是A和B的依赖关系反转了。从A依赖于B变为了B依赖于A。

所以现在几乎所有框架都有控制反转，没有控制反转就不能称为框架，而是工具包。为什么控制反转会有这么大的魔力呢？再仔细思考一下，A与B的依赖关系是如何翻转过来的呢？ 

假如此时把B去掉，A能单独运行吗？很显然，不能，那么B能单独运行吗？很显然，可以。所以从本质上来说，依赖关系并没有反转吗？应该不是，而是讨论A与B的依赖关系的时候，A与B本身就是一个整体，要一起运行的，所以讨论是否能单独运行是没有意义的。

所以，对依赖关系的更深的理解就是，A的变化有没有可能引起B的变化，如果有可能，那么B是依赖于A的。这里的变化是指需不需要修改代码。

再看一下，与其说A需要使用B的某个功能，不如说，A对外声明自己需要使用的功能的规范，B来实现这个功能。从A调用B变成了，B实现A。

再对比一下A调用B和B实现A之间的区别，A调用B是最自然的方式，B实现A需要编写额外的代码-----在A中需要增加一个抽象，在B中需要增加一个该抽象的实现，然后在该抽象的实现中把具体功能实现委托给B的相应类或函数。好处是当A需要更换实现时，可以引入C来实现A，而A不需做任何修改。所以设计就是通过复杂性得增加换取灵活性得增加。

由此可知，当我们编写代码得时候可以先找到需求中会变得地方和不变得地方，然后把不变的地方的逻辑写在A中，会变的逻辑写在B中，这样的程序就会拥有灵活性。