什么是依赖(Dependency)?
依赖是一种关系,通俗来讲就是一种需要。
程序员需要电脑,因为没有电脑程序员就没有办法编写代码,所以说程序员依赖电脑,电脑被程序员依赖。
在面向对象编程中,代码可以这样编写。
class Coder {
// 程序员依赖电脑,并自己new一个
Computer mComputer;
public Coder () {
mComputer = new Computer();
// 使用电脑敲代码
mComputer.coding();
}
}
但是这里有一个问题,程序员只是需要用电脑敲代码而已,但是却做了两件事
- 造一台电脑
- 用这台电脑敲代码
还导致另一个问题,假如程序员要出门,想要带一个笔记本出门。那么还要重新造(new)一台笔记本。
class Coder {
// 自己造个笔记本
Laptop mLaptop;
public Coder () {
mLaptop= new Laptop();
// 使用笔记本敲代码
mComputer.coding();
}
}
依赖倒置 (Dependency inversion principle)
什么是依赖倒置?
依赖倒置是面向对象设计领域的一种软件设计原则。
什么是设计原则?
设计原则是前辈们总结出来的经验,你可以把它们看作是内功心法。
软件设计有5大设计原则,合称 SOLID。
依赖倒置原则的定义如下:
- 上层模块不应该依赖底层模块,它们都应该依赖于抽象。
- 抽象不应该依赖于细节,细节应该依赖于抽象。
乍一看,这会让初学者摸不清头脑。这种学术性的概括语言近乎于软件行业中的哲学。可实质上,它确实称得上是哲学,现在 SOLID 几乎等同于面向对象开发中的金科玉律,但是也正因为它的高度概括、它的晦涩难懂,对于广大初学者而言这是一件非常不友好的事物。
什么是上层模块和底层模块?
对于任何一个组织机构而言,它一定有架构的设计有职能的划分。按照职能的重要性,自然而然就有了上下之分。
公司管理层就是上层,CEO 是整个事业群的上层,那么 CEO 职能之下就是底层。
然后,我们再以事业群为整个体系划分模块,各个部门经理以上部分是上层,那么之下的组织都可以称为底层。由此,我们可以看到,在一个特定体系中,上层模块与底层模块可以按照决策能力高低为准绳进行划分。
什么是抽象和细节?
抽象如其名字一样,是一件很抽象的事物。抽象往往是相对于具体而言的,具体也可以被称为细节,当然也被称为具象。
比如:
1. 这是一幅画。画是抽象,而油画、素描、国画而言就是具体。
2. 这是一件艺术品,艺术品是抽象,而画、照片、瓷器等等就是具体了。
3. 交通工具是抽象,而公交车、单车、火车等就是具体了。
4. 表演是抽象,而唱歌、跳舞、小品等就是具体。
上面可以知道,抽象可以是物也可以是行为。
具体映射到软件开发中,抽象可以是接口或者抽象类形式。
public interface Driveable {
void drive();
}
class Bike implements Driveable{
@Override
public void drive() {
System.out.println("Bike drive.");
}
}
class Car implements Driveable{
@Override
public void drive() {
System.out.println("Car drive.");
}
}
Driveable 是接口,所以它是抽象,而 Bike 和 Car 实现了接口,它们被称为具体。
依赖倒置的好处
在平常的开发中,我们大概都会这样编码。
public class Person {
private Bike mBike;
public Person() {
mBike = new Bike();
}
public void chumen() {
System.out.println("出门了");
mBike.drive();
}
}
我们创建了一个 Person 类,它拥有一台自行车,出门的时候就骑自行车。
public class Test1 {
public static void main(String[] args) {
Person person = new Person();
person.chumen();
}
}
不过,自行车适应很短的距离。如果,我要出门逛街呢?自行车就不大合适了。于是就要改成汽车。
我们需要修改 Person 这个类的代码。
public class Person {
//private Bike mBike;
private Car mCar;
public Person() {
//mBike = new Bike();
mCar = new Car();
}
public void chumen() {
System.out.println("出门了");
//mBike.drive();
mCar.drive();
}
}
不过,如果我要到北京去,那么汽车也不合适了。
class Train implements Driveable{
@Override
public void drive() {
System.out.println("Train drive.");
}
}
public class Person {
//private Bike mBike;
//private Car mCar;
private Train mTrain;
public Person() {
//mBike = new Bike();
//mCar = new Car();
mTrain = new Train();
}
public void chumen() {
System.out.println("出门了");
//mBike.drive();
//mCar.drive();
mTrain.drive();
}
}
我们添加了 Train 这个最新的实现类,然后再次修改了 Person 这个类。
有没有一种方法能让 Person 的变动少一点呢?因为这是最基础的演示代码,如果工程大了,代码复杂了,Person 面对需求变动时改动的地方会更多。
而依赖倒置原则正好适用于解决这类情况。
下面,我们尝试运用依赖倒置原则对代码进行改造。
我们再次回顾下它的定义。
- 上层模块不应该依赖底层模块,它们都应该依赖于抽象。
- 抽象不应该依赖于细节,细节应该依赖于抽象。
首先是上层模块和底层模块的拆分。
按照决策能力高低或者重要性划分,Person 属于上层模块,Bike、Car 和 Train 属于底层模块。
上层模块不应该依赖于底层模块。
但是
public class Person {
//private Bike mBike;
//private Car mCar;
private Train mTrain;
public Person() {
//mBike = new Bike();
//mCar = new Car();
mTrain = new Train();
}
}
Person 这个类显然是依赖于 Bike 和 Car。Person 类中 chumen() 的能力完全依赖于属性 Bike 或者 Car 对象,也就是说 Person 把自己的能力依赖在 Bike 和 Car 身上。
用图来表示就是这样的,Person直接依赖于Bike、Car和Train
上层和底层都应该依赖于抽象。我们的代码中,Person 没有依赖抽象,所以我们得引进抽象。
而底层的抽象是什么,是 Driveable 这个接口。
public class Person {
// private Bike mBike;
// private Car mCar;
// private Train mTrain;
private Driveable mDriveable;
public Person() {
//mBike = new Bike();
//mCar = new Car();
//mTrain = new Train();
mDriveable = new Train();
}
public void chumen() {
System.out.println("出门了");
//mBike.drive();
//mCar.drive();
//mTrain.drive();
mDriveable.drive();
}
}
现在,Person 类中 chumen() 这个方法依赖于 Driveable 接口的抽象,它没有限定自己出行的可能性,任何 Car、Bike 或者是 Train 都可以的。
到这一步,我们可以说是符合了上层不依赖于底层,依赖于抽象的准则了。
那么,抽象不应该依赖于细节,细节应该依赖于抽象又是什么意思呢?
以上面为例,Driveable 是抽象,它代表一种行为,而 Bike、Car、Train 都是实现细节。
Person 需要的是 Driveable,需要的是交通工具,但不是说交通工具一定是 Bike、Car、Train。未来也可能是 AirPlane。
class AirPlane implements Driveable {
@Override
public void drive() {
System.out.println("AirPlane fly.");
}
}
那么一个 Person,它下次出门改成飞机可以吗?当然可以的。因为依赖倒置的缘由,Person 展现出了极度的可扩展性。
所以引入抽象这个概念之后,画成图就是这样的。
上面的内容就是依赖倒置原则。
本来常规编码下,肯定会出现上层依赖底层的情况。
而依赖倒置原则的应用则改变了它们之间依赖的关系,它引进了抽象。上层依赖于抽象,底层的实现细节也依赖于抽象,所以依赖倒置我们可以理解为依赖关系被改变,如果非常纠结于倒置这个词,那么倒置的其实是底层细节,原本它是被上层依赖,现在它倒要依赖与抽象的接口。
可以看到,依赖倒置实质上是面向接口编程的体现。
控制反转 (IoC)
控制反转 IoC 是 Inversion of Control的缩写,意思就是对于控制权的反转,对么控制权是什么控制权呢?
大家重新审视上面的代码。
public class Person {
// private Bike mBike;
// private Car mCar;
// private Train mTrain;
private Driveable mDriveable;
public Person() {
//mBike = new Bike();
//mCar = new Car();
//mTrain = new Train();
mDriveable = new Train();
}
public void chumen() {
System.out.println("出门了");
//mBike.drive();
//mCar.drive();
//mTrain.drive();
mDriveable.drive();
}
}
虽然,chumen() 这个方法不再因为出行方式的改变而变动,但是每次更改出行方式的时候,Person 这个类还是要修改。
Person 类还是要实例化 mDriveable 的接口对象。
这里人的工作是 drive(驾驶),而不是造车。在之前的方法中每一次想要开车,这个人还必须要亲自造(new)一辆车出来。而且每次驾驶不同的交通工具,就要造(new)出相应的交通工具。耦合性太严重,无法专注自己的功能。
Person 自己掌控着内部 mDriveable 的实例化。
现在,我们可以更改一种方式。将 mDriveable 的实例化移到 Person 外面。
public class Person {
private Driveable mDriveable;
// 构造器注入
public Person(Driveable driveable) {
this.mDriveable = driveable;
}
public void chumen() {
System.out.println("出门了");
mDriveable.drive();
}
}
就这样无论出行方式怎么变化,Person 这个类都不需要更改代码了
换句话说Person与交通工具类已经解耦了,现在Person只需要关注自己的功能(chumen),不必自己造(new)车开了。
public class Test1 {
public static void main(String[] args) {
Bike bike = new Bike();
Car car = new Car();
Train train = new Train();
// Person person = new Person(bike);
// Person person = new Person(car);
Person person = new Person(train);
person.chumen();
}
}
在上面代码中,交通工具的创建不是在Person类里面了,而是在Test1类里面。
反转了什么?
有反转就有正转,传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象,也就是正转;而反转则是由容器来帮忙创建及注入依赖对象;为何是反转?因为由容器帮我们查找及注入依赖对象,对象只是被动的接受依赖对象,所以是反转;哪些方面反转了?依赖对象的获取被反转了。
这里引入新的概念,IoC容器
这里我们把创建对象的任务交给了Test1这个类,然后把Test1创建的对象注入进Person类中,这里Test1 在 IoC 中就充当了 IoC 容器 这个角色。而在Spring中,创建对象的任务交给了Spring 的IoC容器.
下面又要引入一个新的概念,依赖注入(DI)
下面我们着重看一下上面出现的这个代码
public class Person {
private Driveable mDriveable;
// 构造器注入
public Person(Driveable driveable) {
this.mDriveable = driveable;
}
public void chumen() {
System.out.println("出门了");
mDriveable.drive();
}
}
主要观察,这里已经没有了new这个关键字,取而代之的是构造函数多了个参数。
这就是依赖注入(Dependency injection),对象是被【注入】进来的,而不是自己new出来的。这里也就解释了控制反转(IoC)和依赖注入的关系(DI)。
控制反转是种设计思想,而依赖注入是他的实现方式。
那么问题又来了,在Spring中依赖注入的方式有几种呢?
常见的有X种,上面用到的是构造器注入
实现依赖注入有 3 种方式:
- 构造函数中注入
- setter 方式注入
- 注解注入(@Autowire)
我们现在一一观察这些方式
构造函数注入
public class Person {
private Driveable mDriveable;
public Person(Driveable driveable) {
this.mDriveable = driveable;
}
public void chumen() {
System.out.println("出门了");
mDriveable.drive();
}
}
- 优点:在 Person 一开始创建的时候就确定好了依赖。
- 缺点:后期无法更改依赖。
setter 方式注入
public class Person {
private Driveable mDriveable;
public Person() {
}
public void chumen() {
System.out.println("出门了");
mDriveable.drive();
}
public void setDriveable(Driveable mDriveable) {
this.mDriveable = mDriveable;
}
}
- 优点:Person 对象在运行过程中可以灵活地更改依赖。
- 缺点:Person 对象运行时,可能会存在依赖项为 null 的情况,所以需要检测依赖项的状态。
public void chumen() {
if ( mDriveable != null ) {
System.out.println("出门了");
mDriveable.drive();
}
}
注解注入
后面详细讲
常见问题
IoC是什么
Ioc—Inversion of Control,即“控制反转”,不是什么技术,而是一种设计思想。在Java开发中,Ioc意味着将你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制。如何理解好Ioc呢?理解好Ioc的关键是要明确“谁控制谁,控制什么,为何是反转(有反转就应该有正转了),哪些方面反转了”,那我们来深入分析一下:
●谁控制谁,控制什么:传统Java SE程序设计,我们直接在对象内部通过new进行创建对象,是程序主动去创建依赖对象;而IoC是有专门一个容器来创建这些对象,即由Ioc容器来控制对 象的创建;谁控制谁?当然是IoC 容器控制了对象;控制什么?那就是主要控制了外部资源获取(不只是对象包括比如文件等)。
●为何是反转,哪些方面反转了:有反转就有正转,传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象,也就是正转;而反转则是由容器来帮忙创建及注入依赖对象;为何是反转?因为由容器帮我们查找及注入依赖对象,对象只是被动的接受依赖对象,所以是反转;哪些方面反转了?依赖对象的获取被反转了。
IoC能做什么
IoC 不是一种技术,只是一种思想,一个重要的面向对象编程的法则,它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象,从而导致类与类之间高耦合,难于测试;有了IoC容器后,把创建和查找依赖对象的控制权交给了容器,由容器进行注入组合对象,所以对象与对象之间是 松散耦合,这样也方便测试,利于功能复用,更重要的是使得程序的整个体系结构变得非常灵活。
其实IoC对编程带来的最大改变不是从代码上,而是从思想上,发生了“主从换位”的变化。应用程序原本是老大,要获取什么资源都是主动出击,但是在IoC/DI思想中,应用程序就变成被动的了,被动的等待IoC容器来创建并注入它所需要的资源了。
IoC很好的体现了面向对象设计法则之一—— 好莱坞法则:“别找我们,我们找你”;即由IoC容器帮对象找相应的依赖对象并注入,而不是由对象主动去找。
IoC和DI
DI—Dependency Injection,即“依赖注入”:组件之间依赖关系由容器在运行期决定,形象的说,即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能,而是为了提升组件重用的频率,并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制,我们只需要通过简单的配置,而无需任何代码就可指定目标需要的资源,完成自身的业务逻辑,而不需要关心具体的资源来自何处,由谁实现。
理解DI的关键是:“谁依赖谁,为什么需要依赖,谁注入谁,注入了什么”,那我们来深入分析一下:
●谁依赖于谁:当然是应用程序依赖于IoC容器;
●为什么需要依赖:应用程序需要IoC容器来提供对象需要的外部资源;
●谁注入谁:很明显是IoC容器注入应用程序某个对象,应用程序依赖的对象;
●注入了什么:就是注入某个对象所需要的外部资源(包括对象、资源、常量数据)。
IoC和DI由什么关系呢?其实它们是同一个概念的不同角度描述,由于控制反转概念比较含糊(可能只是理解为容器控制对象这一个层面,很难让人想到谁来维护对象关系),所以2004年大师级人物Martin Fowler又给出了一个新的名字:“依赖注入”,相对IoC 而言,“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。
总结
- 依赖倒置是面向对象开发领域中的软件设计原则,它倡导上层模块不依赖于底层模块,抽象不依赖细节。
- 控制反转是遵守依赖倒置这个原则而提出来的一种设计模式,它引入了 IoC 容器的概念。
- 依赖注入是为了实现控制反转的一种手段之一。
- 它们的本质是为了代码更加的“高内聚,低耦合”。
参考:
https://blog.csdn.net/briblue/article/details/75093382
https://www.zhihu.com/question/23277575