为什么需要依赖注入

admin管理员组

文章数量:1487745

为什么需要依赖注入

为什么需要“依赖注入”

Case 1

public class Foo {

  private Bar bar;

  public Foo() {

    bar = new Bar();

  }

  public void doSomething(int key) {

    String result = bar.getResult(key);

    //swithch result

  }

}

反模式 ，在构造函数中，初始化了合作类，导致：

• 外部使用者不知道 Foo 里面还依赖了 Bar

• 无法对Bar单元测试，体现在 bar.getResult() 返回真实值，如果和网络、数据库、IO 打交道的话，这是一个很耗时的动作

Case 2

public class Foo {

  private Bar bar=new Bar();

  public Foo(){

  }

  public void doSomething(int key){

  String result = bar.getResult(key);

  //swithch result

  }

}

反模式，虽然没有在构造函数中初始化 Bar 对象，但在字段中直接初始化了 Bar 对象，问题和上面一样

Case 3 使用 Guice 来对依赖进行管理

public class Foo {

  private Bar bar ;

  @Inject

  public Foo(Bar bar) {

  this.bar = bar;

  }

  public String doSomething(int key) {

  return bar.getResult(key);

  }

}

对于使用 Foo 的用户而言，一眼就知道 Foo 内部需要 合作类 Bar, 明白了 Foo 的职责，同时 @Inject 将依赖对象注入，解耦的同时还方便测试

public class TestCase {

  @Mock

  private Bar bar;

  @Before

  public void before(){

  MockitoAnnotations.initMocks(this);

}

  @Test

  public void test(){

  //Arrange

  when(bar.getResult(eq(1))).thenReturn("jack");

  Foo foo=new Foo(bar);

  //Action

  String result = foo.doSomething(1);

  //Assert

  Assert.assertEquals("jack",result);

  }

}

上面可以看到，Mock 了 Bar 对象，Bar 对象的 getResult() 可能是一个比较耗时的功能，所以对它进行了Stub，同时 Foo 不依赖真实的 Bar 对象。

本文参与 腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。 原始发表：2024-10-07，如有侵权请联系 cloudcommunity@tencent 删除前往查看public测试对象管理依赖注入

本文标签： 为什么需要依赖注入