2、抽象不应该依赖于细节,细节应该依赖于抽象。
缺点：耦合太紧密，Light发生变化将影响ToggleSwitch。
将Light作成Abstract，然后具体类继承自Light。
优点：ToggleSwitch依赖于抽象类Light，具有更高的稳定性，而BulbLight与TubeLight继承自Light，可以根据"开放－封闭"原则进行扩展。只要Light不发生变化，BulbLight与TubeLight的变化就不会波及ToggleSwitch。
------------------------------------------------------------------
依赖倒置原则（Dependence Inversion Principle），简称DIP。
定义：High level modules should not depend upon low level modules,Both should depend upon abstractions. Abstractions should not depend upon details,Details should depend upon abstractions.
即：高层模块不应该依赖低层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。
抽象：即抽象类或接口，是不能够实例化的。
细节：即具体的实现类，实现接口或者继承抽象类所产生的类，可以通过关键字new直接被实例化。
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。
依赖倒置原则其本质就是契约式编程，通过抽象（抽象类或接口）使各个类或模块的实现彼此独立，不相互影响，实现模块间的松耦合。使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。如果没有实现这个原则，那么也就意味着开闭原则（对扩展开发，对修改关闭）也无法实现。
在实际编程中，我们一般需要做到如下3点：
•低层模块尽量都要有抽象类或接口，或者两者都有。
•变量的声明类型尽量是抽象类或接口。
•使用继承时遵循里氏替换原则。
依赖倒置有三种方式来实现
1、通过构造函数传递依赖对象；
比如在构造函数中的需要传递的参数是抽象类或接口的方式实现。
2、通过setter方法传递依赖对象；
即在我们设置的setXXX方法中的参数为抽象类或接口，来实现传递依赖对象。
3、接口声明实现依赖对象，也叫接口注入；
即在函数声明中参数为抽象类或接口，来实现传递依赖对象，从而达到直接使用依赖对象的目的。
为方便理解，举一些生活中的例子：
1、AGP插槽。主板和显卡之间关系的抽象。主板和显卡通常是使用AGP插槽来连接的，这样，只要接口适配，不管是主板还是显卡更换，都不是问题。
2、驾照。司机和汽车之间关系的抽象。有驾照的司机可以驾驶各种汽车。
3、电源插座。
设计模式中最能体现DIP原则的是抽象工厂模式。在抽象工厂模式中，工厂和产品都可以是抽象的，如果客户要使用的话，只要关注于工厂和产品的接口即可，不必关注与工厂和产品的具体实现。
DIP对于并行开发的影响：两个类之间有依赖关系，只要制定出他们之间的接口，就可以并行开发了。
备注：
1、什么叫做高层模块依赖于底层模块？
面向过程的开发时，为了复用一些常用代码，通常会把这些代码写成函数库的形式。这样，以后做新项目时，调用这些底层函数就可以了。这就叫做高层模块依赖于底层模块。
高层模块一般和业务逻辑相关，底层模块一般和具体实现相关。
2、何谓“倒置”？
这是因为传统的软件开发方法，如结构化的分析和设计，倾向于创建高层模块依赖于低层模块、抽象依赖于具体的软件结构。实际上，这些方法的目标之一就是去定义描述上层模块如何调用低层模块的层次结构。所以，相对于传统的过程化的方法通常所产生的那种依赖结构，一个设计良好的面向对象的程序中的依赖结构就是“被倒置”的。
来看一下那些依赖于低层模块的高层模块的含义。一个应用中的重要策略决定及业务模型正是在这些高层的模块中。也正是这些模型包含着应用的特性。但是，当这些模块依赖于低层模块时，低层模块的修改将会直接影响到它们，迫使它们也去改变。这种境况是荒谬的。应该是处于高层的模块去迫使那些低层的模块发生改变。应该是处于高层的模块优先于低层的模块。无论如何高层的模块也不应依赖于低层的模块。而且，我们想能够复用的是高层的模块。通过子程序库的形式，我们已经可以很好地复用低层的模块了。当高层的模块依赖于低层的模块时，这些高层模块就很难在不同的环境中复用。但是，当那些高层模块独立于低层模块时，它们就能很简单地被复用了。这正是位于框架设计的最核心之处的原则
3.1 依赖倒置原则的定义
依赖倒置原则（Dependence Inversion Principle，简称DIP）这个名字看着有点别扭，“依赖”还“倒置”，这到底是什么意思？依赖倒置原则的原始定义是：High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions。翻译过来，包含三层含义：
@H_301_237@
高层模块和低层模块容易理解，每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。那什么是抽象，什么又是细节呢？在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。依赖倒置原则在Java语言中的表现就是：
@H_301_237@
更加精简的定义就是“面向接口编程”——OOD（Object-Oriented Design，面向对象设计）的精髓之一。
3.2 言而无信，你太需要契约
采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，减少并行开发引起的风险，提高代码的可读性和可维护性。
证明一个定理是否正确，有两种常用的方法：一种是根据提出的论题，经过一番论证，推出和定理相同的结论，这是顺推证法；还有一种是首先假设提出的命题是伪命题，然后推导出一个荒谬、与已知条件互斥的结论，这是反证法。我们今天就用反证法来证明依赖倒置原则是多么的优秀和伟大！
论题：依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，减少并行开发引起的风险，提高代码的可读性和维护性。
反论题：不使用依赖倒置原则也可以减少类间的耦合性，提高系统的稳定性，减少并行开发引起的风险，提高代码的可读性和维护性。
我们通过一个例子来说明反论题是不成立的。现在的汽车越来越便宜了，也就顶多一个卫生间的价格就可以买到一辆不错的汽车，有汽车就必然有人来驾驶了，司机驾驶奔驰车的类图如图3-1所示。
图3-1 司机驾驶奔驰车类图
奔驰车可以提供一个方法run，代表车辆运行，实现过程如代码清代3-1所示。
司机通过调用奔驰车的run方法开动奔驰车，其源代码如代码清单3-2所示。
有车，有司机，在Client场景类产生相应的对象，其源代码如代码清代3-3所示。
通过以上的代码，完成了司机开动奔驰车的场景，到目前为止，这个司机开奔驰车的项目没有任何问题。我们常说“危难时刻见真情”，我们把这句话移植到技术上就成了“变更才显真功夫”，业务需求变更永无休止，技术前进就永无止境，在发生变更时才能发觉我们的设计或程序是否是松耦合。我们在一段貌似磐石的程序上加上一块小石头：张三司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢？麻烦出来了，那好，我们走一步是一步，我们先把宝马车产生出来，实现过程如代码清单3-4所示。
宝马车也产生了，但是我们却没有办法让张三开动起来，为什么？张三没有开动宝马车的方法呀！一个拿有C照的司机竟然只能开奔驰车而不能开宝马车，这也太不合理了！在现实世界都不允许存在这种情况，何况程序还是对现实世界的抽象，我们的设计出现了问题：司机类和奔驰车类之间是一个紧耦合的关系，其导致的结果就是系统的可维护性大大降低，可读性降低，两个相似的类需要阅读两个文件，你乐意吗？还有稳定性，什么是稳定性？固化的、健壮的才是稳定的，这里只是增加了一个车类就需要修改司机类，这不是稳定性，这是易变性。被依赖者的变更竟然让依赖者来承担修改的成本，这样的依赖关系谁肯承担！证明到这里，我们已经知道伪命题已经部分不成立了。
注意 设计是否具备稳定性，只要适当的“松松土”，观察“设计的蓝图”是否还可以茁壮的成长就可以得出结论，稳定性较高的设计，在周围环境频繁变化的时候，依然可以做到“我自岿然不动”。
我们继续证明，“减少并行开发引起的风险”，什么是并行开发的风险？并行开发最大的风险就是风险扩散，本来只是一段程序的错误或异常，逐步波及一个功能，一个模块，甚至到最后毁坏了整个项目，为什么并行开发就有这个风险呢？一个团队，20人开发，各人负责不同的功能模块，甲负责汽车类的建造，乙负责司机类的建造，在甲没有完成的情况下，乙是不能完全地编写代码的，缺少汽车类，编译器根本就不会让你通过！在缺少Benz类的情况下，Driver类能编译吗？更不要说是单元测试了！在这种不使用依赖倒置原则的环境中，所有的开发工作都是“单线程”的，甲做完，乙再做，然后是丙继续…，这在90年代“个人英雄主义”编程模式中还是比较适用的，一个人完成所有的代码工作，但在现在的大中型项目中已经是完全不能胜任了，一个项目是一个团队的协作结果，一个“英雄”再牛X也不可能了解所有的业务和所有的技术，要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系，那然后呢？依赖倒置原则就隆重出场了！
根据以上证明，如果不使用依赖倒置原则就会加重类间的耦合性，降低系统的稳定性，增加并行开发引起的风险，降低代码的可读性和维护性。承接上面的例子，引入依赖倒置原则后的类图如图3-2所示。
图3-2 引入依赖倒置原则后的类图
建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法，其实现过程如代码清单3-5所示。
代码清单3-5 司机接口
接口只是一个抽象化的概念，是对一类事物的最抽象描述，具体的实现代码由相应的实现类来完成，Driver实现类如代码清单3-6所示。
代码清单3-6 司机类的实现
在IDriver中，通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入了ICar接口，至于到底是哪个型号的Car需要在高层模块中声明。
ICar及其两个实现类的实现过程如代码清单3-7所示。
代码清单3-7 汽车接口及两个实现类
|
1
@H_426_301@
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
public
interface
ICar {
//是汽车就应该能跑
public
void
run();
}
public
class
Benz
implements
ICar{
//汽车肯定会跑
public
void
run(){
System.out.println(
"奔驰汽车开始运行..."
);
}
}
public
class
BMW
implements
ICar{
//宝马车当然也可以开动了
public
void
run(){
System.out.println(
"宝马汽车开始运行..."
);
}
}
|
在业务场景中，我们贯彻“抽象不应该依赖细节”，也就是我们认为抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此我们在高层次的模块中应用都是抽象，Client的实现过程如代码清单3-8所示。
代码清单3-8 业务场景
public class Client {
public static void main(String[] args) {
IDriver zhangSan = new Driver();
ICar benz = new Benz();
//张三开奔驰车
zhangSan.drive(benz);
}
}
Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，zhangSan的显示类型是IDriver，benz的显示类型是ICar，也许你要问，在这个高层模块中也调用到了低层模块，比如new Driver()和new Benz()等，如何解释？确实如此，zhangSan的显示类型是IDriver，是一个接口，是抽象的，非实体化的，在其后的所有操作中，zhangSan都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。当然，张三如果要开宝马车，也很容易，我们只要修改业务场景类就可以，实现过程如代码清单3-9所示。
代码清单3-9 张三驾驶宝马车的实现过程
在新增加低层模块时，只修改了业务场景类，也就是高层模块，对其他低层模块如Driver类不需要做任何修改，业务就可以运行，把“变更”引起的风险扩散降低到最小。
注意 在Java中，只要定义变量就必然要有类型，一个变量可以有两个类型：显示类型和真实类型，显示类型是在定义的时候赋予的类型，真实类型是对象的类型，如zhangSan的显示类型是IDriver，真实类型是Driver。
我们再来思考依赖倒转对并行开发的影响。两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立的运行，而TDD（Test-Driven Development，测试驱动开发）开发模式就是依赖倒置原则的最高级应用。我们继续回顾上面司机驾驶汽车的例子，甲程序员负责IDriver的开发，乙程序员负责ICar的开发，两个开发人员只要制定好了接口就可以独立地开发了，甲开发进度比较快，完成了IDriver以及相关的实现类Driver的开发工作，而乙程序员滞后开发，那甲是否可以进行单元测试（Unit Test）呢？答案是可以，我们引入一个JMock工具，其最基本的功能是根据抽象虚拟一个对象进行测试，测试类如代码清单3-10所示。
代码清单3-10 测试类
|
1
@H_426_301@
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
public
class
DriverTest
extends
TestCase{
Mockery context =
new
JUnit4Mockery();
@Test
public
void
testDriver() {
//根据接口虚拟一个对象
final
ICar car = context.mock(ICar.
class
);
IDriver driver =
new
Driver();
//内部类
context.checking(
new
Expectations(){{
oneOf (car).run();
}});
driver.drive(car);
}
}
|
注意粗体部分，我们只需要一个ICar的接口，就可以对Driver类进行单元测试，从这一点来看，两个相互依赖的对象可以分别进行开发，孤立的单元测试，进而保证并行开发的效率和质量，TDD开发的精髓不就在这里吗？测试驱动开发，先写好单元测试类，然后再写实现类，这对代码的质量有非常大的提高，特别适合研发类项目或在项目成员整体水平比较低的情况下采用。
抽象是对实现的约束，对依赖者而言，也是一种契约，不仅仅约束自己，还同时约束自己与外部的关系，其目的是保证所有的细节不逃脱契约的范畴，确保约束双方按照既定的契约(抽象)共同发展，只要抽象这根基线在，细节就逃脱不了这个圈圈，始终让你的对象做到“言而有信”“言出必行”
3.3 依赖的三种写法
依赖是可以传递的，A对象依赖B对象，B又依赖C，C又依赖D…，生生不息，依赖不止，记住一点：只要做到抽象依赖，即使是多层的依赖传递也无所畏惧！
对象的依赖关系有三种方式来传递，如下所示。
@H_301_237@在类中通过构造函数声明依赖对象，按照依赖注入的说法这种方式叫做构造函数注入，按照这种方式的注入，IDriver和Driver的程序修改后如代码清单3-11所示。
|
1
@H_426_301@
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
public
interface
IDriver {
//是司机就应该会驾驶汽车
public
void
drive();
}
public
class
Driver
implements
IDriver{
private
ICar car;
//构造函数注入
public
Driver(ICar _car){
this
.car = _car;
}
//司机的主要职责就是驾驶汽车
public
void
drive(){
this
.car.run();
}
}
|
在抽象中设置setter方法声明依赖关系，依照依赖注入的说法就是setter依赖注入，按照这种方式的注入，IDriver和Driver的程序修改后如代码清单3-12所示。
代码清单3-12 Setter依赖注入
|
1
@H_426_301@
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
public
interface
IDriver {
//车辆型号
public
void
setCar(ICar car);
//是司机就应该会驾驶汽车
public
void
drive();
}
public
class
Driver
implements
IDriver{
private
ICar car;
public
void
setCar(ICar car){
this
.car = car;
}
//司机的主要职责就是驾驶汽车
public
void
drive(){
this
.car.run();
}
}
|
在接口的方法中声明依赖对象，3.2章节的例子就是采用了接口声明依赖的方式，，该方法也叫做接口注入。
3.4 最佳实践
依赖倒转原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：
@H_301_237@这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。
@H_301_237@很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具类，xxxUtils一般是不需要接口或是抽象类的。还有，如果你要使用类的clone方法，就必须使用实现类，这个是JDK提供一个规范。
@H_301_237@如果一个项目处于开发状态，确实不应该有从具体类派生出的子类的情况，但这也不是绝对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都是可以忍受的。特别是做项目维护的同志，基本上可以不考虑这个规则，为什么？维护工作基本上都是做扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个很大的Bug，何必再要去继承最高的基类呢？
@H_301_237@如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。
@H_301_237@在上一个章节中我们讲解了里氏替换原则，父类出现的地方子类就能出现，再结合本章节的讲解，我们可以得出这样一个通俗的规则： 接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。
讲了这么多，估计大家对“倒置”这个词还是有点不理解，那到底什么是“倒置”呢？我们先说“正置”是什么意思，依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程，这也是正常人的思维方式，我要开奔驰车就依赖奔驰车，我要使用笔记本电脑就直接依赖笔记本电脑，而编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”就是从这里产生的。
依赖倒置原则的优点在小型项目中很难体现出来，例如小于10个人月的项目，使用简单的SSH架构，基本上不费太大力气就可以完成，是否采用依赖倒置原则影响不大。但是，在一个大中型项目中，采用依赖倒置原则可以带来非常多的优点，特别是规避一些非技术因素引起的问题。项目越大，需求变化的概率也越大，通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束，可以减少需求变化引起的工作量剧增的情况。人员的变动在大中型项目中也是时常存在的，如果设计优良、代码结构清晰，人员变化对项目的影响基本为零。大中型项目的维护周期一般都很长，采用依赖倒置原则可以让维护人员轻松地扩展和维护。
依赖倒置原则是六个设计原则中最难以实现的原则，它是实现开闭原则的重要途径，依赖倒置原则没有实现，就别想实现对扩展开放，对修改关闭。在项目中，大家只要记住是“面向接口编程”就基本上抓住了依赖倒转原则的核心。
讲了这么多依赖倒置原则的优点，我们也来打击一下大家，在现实世界中确实存在着必须依赖细节的事物，比如法律，就必须依赖细节的定义。 “杀人偿命”在中国的法律中古今有之，那这里的杀人就是一个抽象的含义，怎么杀，杀什么人，为什么杀人，都没有定义，只要是杀人就统统得偿命，那这就是有问题了，好人杀了坏人，还要陪上自己的一条性命，这是不公正的，从这一点看，我们在实际的项目中使用依赖倒置原则时需要审时度势，不要抓住一个原则不放，每一个原则的优点都是有限度的，并不是放之四海而皆准的真理，所以别为了遵循一个原则而放弃了一个项目的终极目标：投产上线和盈利。作为一个项目经理或架构师，应该懂得技术只是实现目的的工具，惹恼了顶头上司，设计做得再漂亮，代码写得再完美，项目做得再符合标准，一旦项目亏本，产品投入大于产出，那整体就是扯淡！你自己也别想混得更好！
原文链接：https://www.f2er.com/javaschema/285422.html