还记得若干年前第一次接触到Spring框架,概念里它是一个很人性化的Web容器,通常只需要配置bean文件以及数据源,一个demo就能很顺利的跑起来,确实节省了很多代码,可以把更多的精力放在业务逻辑上,但是并不知道其博大精深之处,但凡看到什么设计模式、依赖倒置、控制反转、面向切面,就觉得很费解,很多书一上来就把控制反转的文字概念搬上来,甚至没有举例,让人无所适从。直到前段时间看了一些源码,重拾设计模式,才有点恍然大悟,原来没有那么难理解,当初只是被一些高深的文字唬住了,说这么多不就是为了解耦嘛。
首先了解一下解耦的最基本的原则,
依赖倒置原则(Dependence Inversion Principle,DIP):
A. 上层模块不应该依赖于下层模块,它们共同依赖于一个抽象。
B. 抽象不能依赖于具象,具象依赖于抽象。
DIP原则反复强调了一个词——抽象,意思就是让我们在底层模块或者说更通用的模块中少用具体实现,而应该把具体实现抽象出来,拿抽象来代替具体实现,不就是叫我们采用接口或者抽象类嘛。
举个很简单的例子,我是一个programmer,每天开车上班,假如我的车是奔驰,那么我开车这件事用代码可以表示成
public class Programmer {
private Benz benz;
public void driveBenz() {
benz = new Benz();
benz.start();
}
}
public class Benz {
public void start() {
System.out.println("Benz is started");
}
}
Benz是我的车,所以应当作为我的私有属性,注意Programmer调用了Benz,那么这就形成一个依赖关系,即Programmer类依赖于Benz类,假如没有车或者车子没有启动,我也没法drive嘛。
假如某一天我不想开奔驰了,买了一台宝马来开一开呢,那就得把以上代码几乎全部copy一遍,为Programmer类创建一个driveBMW()方法,同时新增一个BMW类,这样的代码导致我多买一辆车,就得多copy几行代码,我把车卖了,还得删改代码,是不是很繁琐。
其实繁琐的根源就是依赖方之间的耦合度太高,重复的修改代码没有任何好处,还会增加风险,这也违反了DIP原则,DIP要求我们尽可能的使用抽象。所以,不管是奔驰还是宝马,都可以把他们抽象成Car,我们把对具体车型的直接依赖变换成对Car的依赖,这样不管我新增什么车辆,都不用修改Programmer的代码了。假如某一天,我不再是一名programmer,成为一名manager了呢,那么我们又可以抽象出一个Person类出来,这样就不需要为不同的角色实现drive方法了,这就是解耦。
public interface Car {
public void start();
}
public class Benz implements Car {
public void start() {
System.out.println("Benz is started");
}
}
public class Programmer {
// drive方法可以支持各种Car的子类
public void drive(Car car) {
car.start();
}
public static void main(String[] args) {
Programmer p = new Programmer();
Benz benz = new Benz();
p.drive(benz);
}
}
控制反转(Inversion of Control,IoC):调用者不再创建被调用者的实例,由容器创建。这很好理解,就是依赖的双方都不用负责类的实例化操作,我需要哪个对象,容器直接递上来,相当于多了一个管家,所谓衣来伸手、饭来张口,实例化这样的脏活累活全让容器包了。
依赖注入(Dependency Injection,DI):容器创建好实例后再注入调用者称为依赖注入。简单说来,就是容器new完对象然后传递给调用方。Spring支持的注入方式主要有两种:setter注入(setter injection,调用者通过set方法设置被调用类)和构造器注入(constructor injection,调用者通过构造器设置被调用类)。
// 被调用者的抽象
public interface Car {
public void start();
}
// 调用者的抽象
public interface Person {
public void setCar(Car car);
public void drive();
}
// 被调用者的具体类
public class Benz implements Car {
public void start() {
System.out.println("Benz is started");
}
}
// 调用者的具体类
public class Programmer implements Person{
private Car car;
// setter方式注入
public void setCar(Car car) {
this.car = car;
}
public void drive() {
if (this.car != null)
car.start();
}
}
// 容器类
public class MyContainer {
// 容器持有并管理调用者和被调用者,也可以说是容器的资源
private Car car;
private Person person;
public MyContainer() {
// 容器资源可以通过不同方式进行初始化
// 例如,通过读取配置文件获得需要的具体类名称
}
public void programmerDrivesBenz() {
car = new Benz();
person = new Programmer();
// 准备好资源并交付
person.setCar(car);
person.drive();
}
public static void main(String[] args) {
MyContainer c = new MyContainer();
c.programmerDrivesBenz();
}
}
控制反转是依赖倒置的一类,描述调用者与被调用者产生依赖的过程的反转,可以理解为控制权的反转,而依赖注入则是具体的实现方式。控制反转和依赖注入根本目的是为了解耦,通过面向接口的编程,减少核心或者底层模块对具体实现的依赖,核心模块不必关注外部模块的具体实现,依赖关系的建立由第三方容器完成,如,调用不同数据源,这样减少程序的硬编码,提高可扩展性和可伸缩性以及复用性。