Java设计原则的依赖倒置是什么

依赖倒置简介

我们经常在框架开发过程中听说依赖倒置、依赖反转、控制反转、依赖注入、IOC一些名词，我们常听的这些名词和开发设计原则中的依赖反转原则是有关系，我们来看看这几个名词：

• 控制反转（IOC），这个是Spring面试基本上都会问的一个问题，IOC全称Inversion of  Controller，IOC不一定是Spring的特性，Spring是用IOC的一个基础框架；简单理解就是之前通过简单的方法把业务代码冗余在一起，需要改的时候比较麻烦，权限完全由开发者控制，反正意思是通过一些设计模式让开发者不在关系基础开发，只要实现应该实现的功能，权限交由程序控制；

• 依赖注入（DI），全称为Dependency Injection，简单理解就是需要操作的对象通过构造方法、get/set、接口构造的对象，通过外部传入的对象注入新的对象，这个就是依赖注入，Spring就是运用比较好的一个框架；

• 依赖反转原则（DIP），全称为Dependency Inversion Principle，也可以叫依赖倒置原则，意思就是：高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过抽象（abstractions）来互相依赖。除此之外，抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）；

模块概念

我们经常所说的高模块和低模块是指什么？我们怎么区分，或者画图的时候标注关系；

简单来说就是，在调用链上，调用者属于高层，被调用者属于低层。为什么会用这样一个设计呢，追根溯本就是松耦合，不然高模块强绑定低模块，也不会因为底层模块的代码而影响高层模块；但是在实际场景中是否完全有必要遵守这一规则呢？我们来看一个常见的例子：

MVC架构：常用的使用方式Controller-->Service-->Dao,Controller对应Service来说就是高模块，Service对于Dao来说也是高模块，但是我们在实际业务场景中直接通过注入的形式开发，当然有的也可能不会直接注入，通过接口的形式获取对象，这样带来的工作成本就会增加。

那我们就会有一个疑问，使用这一原则会带来工作成本的增加吗？按照我的理解话模块也应该是需要划分一个粒度，也需要分为模块间关系、代码间关键、基础框架设计关系、业务代码关系，我们要去考虑扩展性，如果来说业务基本上不会怎么扩展，完全没有必要用到这一原则。

好莱坞原则

好莱坞原则简称Don‘t call us, we‘ll call you，科普下在好莱坞，把简历递交给演艺公司后就只有回家等待。由演艺公司对整个娱乐项的完全控制，演员只能被动式的接受公司的差使,在需要的环节中，完成自己的演出。这和我们的依赖倒置原则不谋而合，所有依赖倒置原则也就叫好莱坞原则。

好莱坞原则的具体体现是模板方法模式，所有的组件都是被动的，所有的组件初始化和调用都由容器负责。这也是一个基础框架应该考虑的点，主要有以下好处：

• 对基于接口编程的支持

• 减少单件和抽象工厂的依赖

• 降低业务和框架的耦合

• 业务组件可复用,可插拔

依赖框架之Spring

我们需要要理清一个概念IOC是Spring的一个特性，成就了Spring框架的特性，并不是Spring框架创造了IOC。

Spring的IOC有什么作用？所谓IOC，就是由Spring IOC 容器来负责对象的生命周期和对象之间的关系

Spring IOC被注入对象提供被依赖对象也有如下几种方式：构造方法注入、stter方法注入、接口注入。

构造器注入

构造器注入，顾名思义就是被注入的对象通过在其构造方法中声明依赖对象的参数列表，让外部知道它需要哪些依赖对象。构造器注入比较简单，通过构造方式构造完成之后就完全可以使用。

TestBean(Test test){
      this.test = test;
}

setter 方法注入

对于 JavaBean 对象而言，我们一般都是通过 getter 和 setter 方法来访问和设置对象的属性。所以，当前对象只需要为其所依赖的对象提供相对应的 setter 方法，就可以通过该方法将相应的依赖对象设置到被注入对象中。相比于构造器注入，setter 方式注入会显得比较宽松灵活些，它可以在任何时候进行注入

public class TestBean {

    private Test test;

    public void setTestBean(Test test) {
        this.test = test;
    }
}

接口方式注入

接口方式注入显得比较霸道，因为它需要被依赖的对象实现不必要的接口，所以我们要合理去使用这种场景，一般在基础框架中很少存在，在业务领域就用的比较多了。

注解注入

现在Spring主流注入方式主要通过注解去做实现，都是基于元注解@Component去实现，也就与@Component产生很多派生注解。

@Autowrited
private TestBean testBean;

@Component
public TestBean(){

}