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 依赖的三种写法
1700455273
1700455274
依赖是可以传递的，A对象依赖B对象，B又依赖C,C又依赖D……生生不息，依赖不止，记住一点：只要做到抽象依赖，即使是多层的依赖传递也无所畏惧！
1700455275
1700455276
对象的依赖关系有三种方式来传递，如下所示。
1700455277
1700455278
1.构造函数传递依赖对象
1700455279
1700455280
在类中通过构造函数声明依赖对象，按照依赖注入的说法，这种方式叫做构造函数注入，按照这种方式的注入，IDriver和Driver的程序修改后如代码清单3-11所示。
1700455281
1700455282
代码清单3-11 构造函数传递依赖对象
[
上一页 ]
[ :1.700455233e+09 ]
[
下一页 ]