面向对象进行程序设计的时候有五大基本的原则，分别是：
1、单一职责原则（SRP）
2、开放封闭原则（OCP）
3、里氏替换原则（LSP）
4、依赖倒置原则（DIP）
5、接口隔离原则（ISP）
然后说一下依赖倒置原则，它的原始的定义包括两个部分：
1、高层模块不该依赖于底层模块，它们都该依赖于抽象。
2、抽象不依靠于(具体)细节，细节应该依赖于抽象。
英文原文：Highlevel modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions。
上面的抽象指的是接口或者抽象类。细节指的是具体的类。依赖这个词，是一个对于多个事物来说的， 可以解释为依靠。
比如在对象A中的方法中调用了对象B的方法或者熟悉，这就可以说是对象A依赖于对象B，因为对象A只有''依靠''对象B才能完成某些功能。
又比如，抽象类A或者中约定了一些公共方法，类B实现或者继承了A，对它的细节进行了完善，那么这个B是依赖于A的，因为B的基本功能框架是通过A才能实现的。
所以一般如果没有考虑依赖倒置的设计，对象和对象之间的依赖是一种直接的依赖，这是一种紧耦合的设计，当被依赖的一方发生变化的时候，依赖的一方也需要被迫进行改变。
自顶而下的程序设计中，通常会将某个业务逻辑划分成为一个模块，而它的实现是通过一些粒度比较小的功能点进行完成的，小的功能点又可以由更小的功能实现，在面向对象的编程中，每一个都是对象，所以高层模块的功能是通过许多底层模块的功能实现的，高层模块调用底层模块，也就是高层模块依赖于底层模块。
之前说过了，这样的直接依赖，将会使得两者之间产生强耦合，一般底层模块是比较细节的，而细节的东西变化比较频繁，所以底层模块一旦需要变化了，由于高层模块是直接依赖于底层的，那么高层模块也必须改变，而开闭原则所要求的是程序对修改关闭，对扩展开放。而且频繁的修改高层模块的代码，也会很容易引入错误。
所以为了解决这个问题，可以对于具体的实现类加上抽象，它们的依赖关系不通过具体的实现类，而是抽象之间的依赖，这样的话，细节的类需要变化了，不影响高层模块类的使用，因为对于高层的模块（或者说是原来依赖方）来说，它看到的只是抽象，具体的实现细节它是看不见的。而抽象是比较稳定的，不会发生变化。所以高层的模块不需要改变。
依赖倒置的核心其实是面向接口编程，总结出来是如下几个原则。
1、尽量不要用直接依赖，而是通过抽象进行依赖，即每个类最好有抽象。
2、依赖关系的对象引用变量用抽象的类型。
3、任何类不要从具体的类派生。
4、不要重写基类的方法。
通过依赖倒置的设计，有利于并行的程序开发，假如甲开发类A，乙开发类B，A依赖于B，那么当乙还没有开发完成的时候，甲也没办法将A的开发继续下去，因为没办法去测试其功能。而如果采用依赖倒置设计类的依赖的话，乙只需要提供B的抽象，而甲根据抽象就可以进行开发和测试。
依赖是可以进行传递的，java中提供了好几种的传递依赖的方法，传递依赖就是指将所需要的被依赖对象注入到需要依赖内。
1、通过构造函数的参数申明来传递依赖对象。
2、通过set方法将依赖对象注入。
3、接口申明依赖对象，在接口定义的某个方法中，将依赖对象的抽象作为形参。
Spring的两大特点是IOC和AOP，IOC叫做控制反转，AOP叫做面向切面编程。
之所以叫做控制反转，是因为通过没有通过spring框架，一般的假如对象A依赖于对象B的话，如上所诉，会有一个依赖注入的过程，这种依赖注入的控制的主动权在我们，我们决定何时以何种方式进行注入，但是spring提供了ioc的容器，使得对象的生成以及对象依赖关系之间的依赖对象的注入由IOC容器来完成。反转的真是对象注入的权利，现在有IOC容器来控制，所以IOC也称为依赖注入DI，实际上，依赖注入是控制反转的手段。