1700455223
1700455224
}
1700455225
1700455226
}
1700455227
1700455228
在新增加低层模块时，只修改了业务场景类，也就是高层模块，对其他低层模块如Driver类不需要做任何修改，业务就可以运行，把“变更”引起的风险扩散降低到最小。
1700455229
1700455230
注意 在Java中，只要定义变量就必然要有类型，一个变量可以有两种类型：表面类型和实际类型，表面类型是在定义的时候赋予的类型，实际类型是对象的类型，如zhangSan的表面类型是IDriver，实际类型是Driver。
1700455231
1700455232
我们再来思考依赖倒置对并行开发的影响。两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立地运行，而TDD（Test-Driven Development，测试驱动开发）开发模式就是依赖倒置原则的最高级应用。我们继续回顾上面司机驾驶汽车的例子，甲程序员负责IDriver的开发，乙程序员负责ICar的开发，两个开发人员只要制定好了接口就可以独立地开发了，甲开发进度比较快，完成了IDriver以及相关的实现类Driver的开发工作，而乙程序员滞后开发，那甲是否可以进行单元测试呢？答案是可以，我们引入一个JMock工具，其最基本的功能是根据抽象虚拟一个对象进行测试，测试类如代码清单3-10所示。
1700455233
1700455234
代码清单3-10 测试类
1700455235
1700455236
public class DriverTest extends TestCase{
1700455237
1700455238
Mockery context=new JUnit4Mockery（）；
1700455239
1700455240
@Test
1700455241
1700455242
public void testDriver（）{
1700455243
1700455244
//根据接口虚拟一个对象
1700455245
1700455246
final ICar car=context.mock（ICar.class）；
1700455247
1700455248
IDriver driver=new Driver（）；
1700455249
1700455250
//内部类
1700455251
1700455252
context.checking（new Expectations（）{{
1700455253
1700455254
oneOf（car）.run（）；
1700455255
1700455256
}}）；
1700455257
1700455258
driver.drive（car）；
1700455259
1700455260
}
1700455261
1700455262
}
1700455263
1700455264
注意粗体部分，我们只需要一个ICar的接口，就可以对Driver类进行单元测试。从这一点来看，两个相互依赖的对象可以分别进行开发，孤立地进行单元测试，进而保证并行开发的效率和质量，TDD开发的精髓不就在这里吗？测试驱动开发，先写好单元测试类，然后再写实现类，这对提高代码的质量有非常大的帮助，特别适合研发类项目或在项目成员整体水平比较低的情况下采用。
1700455265
1700455266
抽象是对实现的约束，对依赖者而言，也是一种契约，不仅仅约束自己，还同时约束自己与外部的关系，其目的是保证所有的细节不脱离契约的范畴，确保约束双方按照既定的契约（抽象）共同发展，只要抽象这根基线在，细节就脱离不了这个圈圈，始终让你的对象做到“言必信，行必果”。
1700455267
1700455268
1700455269
1700455270
1700455272
设计模式之禅 3.3 依赖的三种写法
[
上一页 ]
[ :1.700455223e+09 ]
[
下一页 ]