依赖注入及AOP简述(五)——依赖注入的方式 .

二、依赖注入的应用模式

前面我们了解了依赖注入的基本概念,也对一些依赖注入框架进行了简单的介绍,这一章我们主要来讨论作为开发者如何利用依赖注入框架来实现依赖注入的设计思想。

1.     依赖注入的方式

前面我们提到,所谓“依赖”,最简单地去解释就是一个Java类里的成员变量。我们都知道,给一个类中的私有成员变量赋值的方法通常有:通过Constructor构造方法、通过Setter方法、通过反射机制将私有变量的可见性设为true这三种方法。同样道理,依赖注入框架也是利用这三种方式来完成依赖对象的设定的,我们分别称之为Constructor注入、Setter注入、成员变量注入。

这里有两点需要注意的地方。一是除了这三种常见的注入方式,还有一些其他的注入方式,例如Spring框架中提供的lookup-method为代表的方法注入模式,也被称作“装饰器”模式,还有像Guice中的方法参数注入等等,我们在此不再详加讨论。二是并不是所有的依赖注入框架都提供这三种常见的注入方式,比如Seam2.x版本里就不支持Constructor注入的方式。

1.1.    Constructor注入

利用Constructor注入,即在依赖者类的构造函数上声明注入点,而要被注入的对象则是构造函数的参数。

我们来看利用Spring框架的例子。首先我们将Bank和DepositBook两个依赖类声明为Spring容器管理的组件:

@Component // 声明此依赖为Spring组件

public class BankICBC implements Bank { // ……  }

@Component // 声明此依赖为Spring组件

public class DepositBookICBC implements DepositBook { // ……  }

这里我们采用Spring
3.x提供的@Component方式来声明Spring组件,当然还有很多其它的方式,就不再详细阐述了。将这两个依赖声明为Spring容器管理的组件之后,它们就可以在被需要的时候由容器提供给依赖者了。例如在储户Depositor类中,我们定义了以Constructor为注入点的依赖请求:

@Component

public class Depositor {

@Autowired  // Constructor注入点

public Depositor(Bank bank, DepositBook
depositBook) {

this.bank = bank;

this.depositBook = depositBook;

}

private Bank bank;

private DepositBook depositBook;

public Cash withDraw(BigDecimal amount) {

return bank.withDraw(depositBook,
amount);

}

}

之后主程序在调用这个Depositor类的时候,容器就会自动将保管的依赖对象设定好之后分发给主程序了。

public void runSpringConstructorDI() {

AnnotationConfigApplicationContext context =

new
AnnotationConfigApplicationContext("tutorial.di.ch01");

Depositor depositor =
context.getBean(Depositor.class);

depositor.withDraw(new
BigDecimal(10000));

}

1.2.    Setter注入

第二种常用的声明注入点的方法是Setter注入,即依赖注入框架利用反射机制调用依赖者类的Setter方法来完成依赖注入。

我们来看利用Seam框架的例子。首先还是要将Bank和DepositBook两个依赖类声明为Seam容器管理的组件:

@Name("bank")

public class BankICBC implements
Bank { // ……  }

@Name("depositBook")

public class DepositBookICBC
implements DepositBook { // …… 
}

之后在依赖者Depositor类中的Setter方法处声明注入点:

@Name("depositor")

public class Depositor {

private Bank bank;

private DepositBook depositBook;

@In  // bank的Setter注入点

public void setBank(Bank bank) {

this.bank = bank;

}

@In  // depositBook的Setter注入点

public void setDepositBook(DepositBook
depositBook) {

this.depositBook = depositBook;

}

public Cash withDraw(BigDecimal amount) {

return bank.withDraw(depositBook,
amount);

}

}

注意Seam框架缺省是将与该依赖字段同名的标识符所绑定的依赖对象注入进来,如果想注入与字段名不同的标识符得依赖对象,需要使用@In(“依赖对象标识符”)这样的语法。

1.3.    成员变量注入

成员变量注入是指依赖注入框架利用反射机制,直接将依赖者类的成员变量set为容器管理的依赖对象。

仍以Seam框架为例,与刚才Setter注入模式唯一不同的就是将@In标注在成员变量旁,而不是其Setter方法上。

@Name("depositor")

public class Depositor {

@In  // bank的成员变量注入点

private Bank bank;

@In  // depositBook的成员变量注入点

private DepositBook depositBook;

public Cash withDraw(BigDecimal amount) {

return bank.withDraw(depositBook,
amount);

}

}

1.4.    注入模式的选择

对于该怎么使用前面介绍的这几种注入模式,究竟在什么情况下该使用哪种,这是一个讨论非常广泛的话题。这里只举一个简单的例子来说明,比如要设计一个不可变(final)依赖的类,则必须使用Constructor注入方式:

@Component

public class Depositor {

@Autowired  // Constructor注入点

public Depositor(Bank bank, DepositBook
depositBook) {

this.bank = bank;

this.depositBook = depositBook;

}

private final Bank bank; // 不可变的依赖

private final DepositBook depositBook; //
不可变的依赖

public Cash withDraw(BigDecimal amount) {

return bank.withDraw(depositBook,
amount);

}

}

再如如果一个类所拥有的依赖数量过多、而开发者又不想构造方法的参数成为“过长参数列表”(这是一种影响代码的可读性和可维护性的反模式,Martin
Fowler于1999年在其《Refactoring:Improving the Design of Existing
Code》一书中提出),则可考虑Setter注入或者成员变量注入。此外,如果遇到了类似“循环依赖”的情况,例如宿主和寄生动物这两个对象就属于相互依存的“循环依赖”模式,这样的情况下,我们就可能需要Constructor和Setter两种混合的模式才能解决。总而言之,选择依赖注入模式是一个很大的话题,我们在此就不再深入讨论了。

时间: 2024-08-25 16:24:01

依赖注入及AOP简述(五)——依赖注入的方式 .的相关文章

依赖注入及AOP简述(三)——依赖注入的原理

3.     “依赖注入”登场 于是诸多优秀的IT工程师开始想出了更加轻量便利.更加具有可测试性和可维护性的设计模式——IoC模式.IoC,即Inversion of Control的缩写,中文里被称作“控制反转”.至于为什么会有这么一个看似古怪的名字,我们稍后会做解释.2004年著名软件工程学者和工程师Martin Fowler在其论文<Inversion ofControl Containers and the Dependency Injection pattern>中将IoC更名为De

依赖注入及AOP简述(九)——单例和无状态Scope .

三.依赖注入对象的Scope及其生命周期 在前面的章节我们讲到,依赖注入容器之所以能够区别于以往的ServiceLocator等容器,是在于其不但能够自动构建多层次的.完整的依赖关系图,并且可以管理依赖对象的Scope和对其进行行为增强.有关行为增强的话题我们会在下一章介绍,这里我们先来看看有关依赖对象的Scope及其生命周期管理的话题. 1.     依赖注入对象的Scope Scope,即作用域,是指面向对象开发中所设计的某一类对象的生存期间.我们先从普通Java程序开发中最常用的单例和无状

依赖注入及AOP简述(四)——“好莱坞原则”和依赖注入框架简介 .

3.2.    “好莱坞原则” 看了前面关于依赖注入概念的描述,我们来提炼出依赖注入的核心思想.如果说传统的组件间耦合方式,例如new.工厂模式等,是一种由开发者主动去构建依赖对象的话,那么依赖注入模式则是其反向的,即被动地等待别人做好一个依赖对象提供给我. 在美国好莱坞众多电影工厂在寻找演员的时候通常奉行着这么一个原则:不要找我,需要的时候我去找你(“Don’tcall us; we’ll call you!”),把相同的思路运用到我们的软件工程里通常也被称作“好莱坞原则”(Hollywood

依赖注入及AOP简述(七)——FQCN请求模式

2.2.    FQCN请求模式 为了弥补纯字符串请求模式中的类型安全问题,全类名(FQCN)请求模式就应运而生了.其思想便是,在向容器请求依赖对象的时候,不是通过字符串的标识符.而是通过被请求的依赖的全类名来定位依赖.这样如果开发者误将全类名标识符写错的话,在编译时立即会提醒“类不存在”.并且,如果使用Eclipse等IDE开发工具的话,用其提供的自动完整代码的功能就会轻松地将依赖的全类名标识符定义到代码中. 在第一章的“3.3 依赖注入框架简介”一节中我们提到了Google Guice框架是

依赖注入及AOP简述(十一)——生命周期管理 .

2.     生命周期管理 各种依赖注入框架提供了替开发者管理各种Scope的便利功能,随之而来的就必然是被管理的依赖对象的生命周期管理的问题.所谓生命周期管理,就是一个对象在它所属的Scope中从被容器创建开始.到被提供给依赖者.再到最后的消亡这一整个过程中,依赖注入框架提供了一系列的回调方法的接口,使框架自身以及开发者都可以利用这些接口对各个生存时点的依赖对象做一些操作和管理等. 例如依赖注入容器在创建一个依赖对象的时候,远不是new一个对象那么简单,而是一个极其复杂地Wrap这个对象的过程

依赖注入及AOP简述(一)——“依赖”的概念 .

一.入门:依赖注入 作为一种全新的设计模式理念,“依赖注入”这个词汇在软件设计开发中已经是越来越耳熟能详了,而各种流行于开源社区的“依赖注入框架”,也越来越多的被当作软件工程开发过程中使用的基础框架.这一章我们主要介绍什么是依赖注入.它的来源是什么.以及能给我们带来什么样的好处. 1.     “依赖”的概念 要了解依赖注入,我们首先需要了解什么是“依赖”.从现实世界的观点来看,“依赖”即某个实体对象为了完成某项功能,必须要依托另外一些实体对象,那么这些被依托的实体对象即被称为“依赖”(Depe

依赖注入及AOP简述(六)——字符串请求模式 .

2.     依赖注入对象的请求模式 前一节我们讨论了关于声明注入点的几种方法,这一节主要来介绍在注入点上如何定位到所需要的标识符的话题.基本上,我们可以用字符串为标识符来请求依赖对象.或者用全类名(FQCN)为标识符来请求依赖对象.或者用两者混合的模式.下面我们来依次介绍. 2.1.    字符串请求模式 顾名思义,字符串请求模式即依赖注入框架将一个依赖绑定到指定的字符串上,而后将其装入依赖注入容器.依赖者通过这个字符串,向容器请求所需要的依赖.Seam和Spring都是典型的基于字符串请求模

依赖注入及AOP简述(十二)——依赖注入对象的行为增强(AOP) .

四.依赖注入对象的行为增强(AOP) 前面讲到,依赖注入框架的最鲜明的特点就是能够提供受容器管理的依赖对象,并且可以对对象提供行为增强(AOP)功能,所以这一章我们来讨论有关AOP的话题. 1.     对依赖对象进行行为增强 所谓AOP,就是Aspect Oriented Programming(面向方面的编程),核心思想是把一个“方面”独立出来,从而实现组件间的松耦合.也许有些晦涩难懂,所以我们还是看个简单的例子. 在我们的银行依赖中,假设有个需求,即在每一笔取款业务的前后都要输出日志信息.

依赖注入及AOP简述(十三)——AOP应用举例(完结) .

2.     AOP应用举例 在一般的应用程序开发中,有一些典型的AOP应用,使得开发者可以专注于业务逻辑本身,而不是与之完全无关的一些“方面”. l        首先就是关于前面介绍过的日志输出类的功能,当然前面的例子非常简单,实际上要输出的日志信息中往往有很多的可变参数,这时就需要从被拦截对象的上下文中取出相应的信息进行行为的增强. l        最常用的AOP应用就是关于DB事务的管理了.业务处理成功则向DB提交事务,反之则回滚事务——这是每一个开发者都会写过的代码.但是实际上这种事