依赖注入是什么?

依赖注入(Dependency Injection)
Spring的两个核心内容为控制反转(Ioc)和面向切面(AOP),依赖注入(DI)是控制反转(Ioc)的一种方式。

依赖注入这个词让人望而生畏,现在已经演变成一项复杂的编程技巧 或设计模式理念。但事实证明,依赖注入并不像它听上去那么复杂。 在项目中应用DI,你会发现你的代码会变得异常简单并且更容易理解 和测试。

DI功能是如何实现的

任何一个有实际意义的应用(肯定比Hello World示例更复杂)都会由 两个或者更多的类组成,这些类相互之间进行协作来完成特定的业务 逻辑。按照传统的做法,每个对象负责管理与自己相互协作的对象(即它所依赖的对象)的引用,这将会导致高度耦合和难以测试的代 码。

举个例子,考虑下程序清单1.2所展现的Knight类。

DamselRescuingKnight只能执行RescueDamselQuest 探险任务

可以看到,DamselRescuingKnight在它的构造函数中自行创建了 Rescue DamselQuest。这使得DamselRescuingKnight紧密地 和RescueDamselQuest耦合到了一起,因此极大地限制了这个骑 士执行探险的能力。如果一个少女需要救援,这个骑士能够召之即 来。但是如果一条恶龙需要杀掉,或者一个圆桌……额……需要滚起 来,那么这个骑士就爱莫能助了。

更糟糕的是,为这个DamselRescuingKnight编写单元测试将出奇 地困难。在这样的一个测试中,你必须保证当骑士的 embarkOnQuest()方法被调用的时候,探险的embark()方法也要 被调用。但是没有一个简单明了的方式能够实现这一点。很遗 憾,DamselRescuingKnight将无法进行测试。

耦合具有两面性(two-headed beast)。一方面,紧密耦合的代码难以 测试、难以复用、难以理解,并且典型地表现出“打地鼠”式的bug特 性(修复一个bug,将会出现一个或者更多新的bug)。另一方面,一 定程度的耦合又是必须的——完全没有耦合的代码什么也做不了。为 了完成有实际意义的功能,不同的类必须以适当的方式进行交互。总 而言之,耦合是必须的,但应当被小心谨慎地管理。

通过DI,对象的依赖关系将由系统中负责协调各对象的第三方组件在 创建对象的时候进行设定。对象无需自行创建或管理它们的依赖关系,如图1.1所示,依赖关系将被自动注入到需要它们的对象当中 去。 

 

依赖注入会将所依赖的关系自动交给目标对象,而不是让对象自己去获取 依赖 为了展示这一点,让我们看一看程序清单1.3中的BraveKnight,这 个骑士不仅勇敢,而且能挑战任何形式的探险。

BraveKnight足够灵活可以接受任何赋予他的探险任 务 我们可以看到,不同于之前的 DamselRescuingKnight,BraveKnight没有自行创建探险任 务,而是在构造的时候把探险任务作为构造器参数传入。这是依赖注 入的方式之一,即构造器注入(constructor injection)。

更重要的是,传入的探险类型是Quest,也就是所有探险任务都必须 实现的一个接口。所以,BraveKnight能够响应 RescueDamselQuest、 SlayDragonQuest、 MakeRound TableRounderQuest等任意的Quest实现。

  • 10
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
假设有一个类A需要使用类B的功能,如果在A类中直接实例化B类,那么A类和B类之间的依赖关系就会很紧密,难以达到解耦的目的。而使用依赖注入的方式,A类不再直接实例化B类,而是将B类的实例通过构造函数、属性、或者接口等方式注入到A类中。 举个例子,比如一个电商网站需要发送短信验证码,可以使用短信服务商提供的API来实现。在不使用依赖注入的情况下,发送短信验证码的代码可能是这样的: ``` public class SmsService { public void sendSms(String phoneNumber, String code) { SmsSender smsSender = new SmsSender(); smsSender.send(phoneNumber, code); } } ``` 这里的SmsSender是一个实现了短信发送功能的类,但是直接在SmsService类中实例化SmsSender类,会导致SmsService类和SmsSender类之间产生了紧密的耦合关系。如果以后需要更换短信服务商,就需要修改SmsService类的代码。 而使用依赖注入的方式,可以将SmsSender类的实例通过构造函数注入到SmsService类中,代码可能是这样的: ``` public class SmsService { private ISmsSender smsSender; public SmsService(ISmsSender smsSender) { this.smsSender = smsSender; } public void sendSms(String phoneNumber, String code) { smsSender.send(phoneNumber, code); } } ``` 这里的ISmsSender是一个接口,SmsSender类实现了这个接口,通过构造函数注入的方式将SmsSender类的实例注入到了SmsService类中。这样,SmsService类就不再依赖于具体的短信服务商,可以更加灵活地进行扩展和维护。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值