深一层看依赖注入
深一层看依赖注入
from:http://www.cnblogs.com/weidagang2046/archive/2009/12/10/1620587.html
依赖注入(DI)是控制反转(IoC)的一种方式。目前,在.NET和Java领域已经有相当多基于DI思想的对象容器,如:Spring,Unity等。本文试图避免重复性地介绍DI基础知识和DI容器的使用,而是希望深一层探讨DI的本质和对象间关系,以达到合理设计避免滥用DI的目的。
依赖注入 vs 创建对象
有不少地方这样描述:“依赖注入改变了使用对象前先创建的传统方式,而是从外部注入依赖的对象”。先来看一个例子:
interface ICar{
void Run();
}
class Person{
public ICar Car {
get { return m_car; }
set { m_car = value; }
}
public void Drive() { m_car.Run(); }
private ICar m_car;
}
Person不主动创建所依赖的ICar对象,而是通过DI方式注入。应该说这是一种合理的设计,但如果接本段开头的话说“依赖注入改变了人使用汽车之前先创建的传统方式”您会不会觉得别捏呢?我们来看看所谓的“传统方式”是什么样子:
class Benz : ICar{
void Run() {}
}
class Person{
public void Drive() {
ICar car = new Benz(); m_car.Run();
}
}
这就是Drive之前先创建ICar对象,“传统方式”并不传统,因为它非常不自然。我们肯定在偷笑“这个人家里一定是开银行的,要开车的时候临时买一辆奔驰,开完马上扔给垃圾回收站”。这说明DI并非都是反传统的求新求变,在某些情况下它本身就是一种合理的设计。不过,这里话才说了一半,上面的例子是说“不该创建对象的时候,DI本来就是一种合理的设计”,下面还有另一半“该创建对象的时候,用DI反而不合理”。
class Person{
public Person(IHeart heart) { m_heart = heart; }
private IHeart m_heart;
}
大家看看上面这位老兄在干嘛呢?心脏也依赖注入?这就是典型的滥用依赖注入。我们来分析一下这种方式的问题在哪儿:
1. 暴露内部实现:假设m_heart只是内部实现相关的对象,上面的方式就暴露了内部实现,造成外部程序对Person的内部实现的变化变得敏感;
2. 依赖对象状态被外部修改:由于m_heart是从外部注入的,外部可能依然持有m_heart的引用,因此完全可能被有意无意地修改掉。
本质上,这种滥用DI的问题其实是对OO封装的破坏。如果采用创建对象的方式,这个例子就合理多了:
class Heart : IHeart { ... }
class Person{
public Person() { m_heart = new Heart(); }
private IHeart m_heart;
}
Person在其构造函数内自行创建m_heart显然是合理的设计,不存在上面强行引入DI造成的破坏封装问题。
莫忘工厂
但是喜欢DI的朋友可能会说:“这个例子里面DI方式也有好处啊,抛开领域建模是否合理不谈,DI方式起码没有依赖具体的Heart类,这样就使得类之间变成松耦合关系。比如要测试Person类的时候可以Mock一个IHeart对象,而创建对象的方式就不行”。
这种说法点出了DI的一个显著好处,但是他和多数滥用DI的人一样犯了同样的毛病:有了DI忘了工厂。没错,用new创建对象的确是一种紧耦合方式,但抽象工厂模式正是为解决构造函数不能多态的问题,所以又称为“虚构造函数”。我们只需用采用抽象工厂模式,让Person依赖于一个IHeartFactory接口,然后从外部注入工厂实例,最后从这个工厂创建IHeart对象即可。由于统统是依赖接口,我们可以Mock一个工厂,出品一个Mock的Heart达到可测试性要求。
当然,关于IHeartFactory的命名有值得商榷的地方,毕竟在此环境下不适合用“工厂”这个词,但这不影响我们要表达的主要意思。重要的是体会即使没有工厂模式,我们还是应该采用创建对象方式,该耦合的时候耦合,不该耦合的时候不耦合。设计应追求两个字:合理!
[备注:实际上即使是采用了工厂模式,依然有暴露内部实现的嫌疑,因为如果heart是纯内部实现相关,暴露IHeart和IHeartFactory给外部已经是损害了封装,何况还需要外部提供具体的factory对象。不过,重要的是体会到工厂和new一样,体现的是对对象生命周期的管理,让外部无法接触到内部对象;而工厂的目的是多态性。]
对象间依赖关系
上面的两个例子从不同方面说明了DI和对象创建谁也不能取代谁,应该根据情况采用合理的设计。那么我们自然要问,合理的标准在哪里呢,有没有明确的指导方针供我们设计时参考呢?答案是有!那就是对象间关系。在OO中,对象间关系的大致可分为两类:纵向关系和横向关系。纵向主要指继承关系,比较容易区分;但横向关系比较微妙。从本文的例子中我们已经明显感觉到了横向关系是需要仔细区分的。
按UML建议横向关系大体分为4种,它们的耦合程度由弱到强:
依赖 < 关联 < 聚合 < 组合
1. 依赖(Dependency):语义“a uses b”,a依赖于b,但不持有b的引用;比如:现实世界的例子有“人对空气的依赖关系”,在程序中a.f(b)可以理解为a对b的依赖(或者说对b的类型B的依赖),b作为a的方法参数,a内部成员变量不引用b。UML符号:
2. 关联(Association):语义“a has b”,a拥有b的引用,但a和b无从属关系,二者是一种松散的关联关系,可以随时解除或建立;比如“朋友关系”。UML符号:
3. 聚合(Aggregation):语义“a owns b”,a拥有b的引用,且有从属关系,二者的耦合比关联更强,但a并不负责b的生命周期;比如,本文中人与汽车的关系。UML符号:
4. 组合(Composition):语义“b is a part of a”,a不仅拥有b的引用,还应该全权负责b的整个生命周期,在程序中b通常是a的内部实现细节,不暴露给外部;比如本文中人与心脏的关系。UML符号:
我们注意这四种关系中有一个关键的概念“对象生命周期”,在建模时辨别清楚对象生命周期就不难选择采用DI还是创建对象。DI意味着使用者不负责依赖对象的生命周期,创建对象则相反。对应到上面的4种横向关系,我们一般可以这样处理:第1种依赖关系不需要DI也不需要创建对象;第2,3种关联和聚合关系适合采用DI方式,最后一种组合关系适合采用创建对象方式。
[备注:聚合(Aggregation)的owns语义似乎并非“人拥有汽车”的“拥有”,而更接近“人群与人”的集合与元素的关系,所以文中“人与汽车”关系更接近关联(Association)。待进一步查证资料。]
注入方式的选择
在决定采用DI设计后,马上要考虑的是注入方式问题。DI中注入方式主要有构造函数注入和Setter注入(还有接口注入较少使用,本文不讨论)。这里我们还是通过具体例子来体会二者的区别:“人与身份证的依赖关系”适合采用Setter注入,因为人不是一出生就有身份证,而是到了法定年龄才有,用构造函数注入表达的语义与此相违背。相反“人与父母的依赖关系”则适合采用构造函数注入,因为亲子关系是从人一出生就建立的,用Setter注入必然使得对象创建后有一段时间处于非法状态,按契约式设计的术语即破坏了对象的不变量(invariant)。
可见,选择的关键还是对象生命周期问题。对象生命周期本身是现实世界的重要概念,因此,它在对现实世界建模见长的OO设计中当然也非常重要。不同OO语言间对象生命周期管理也有很大差别,主流OO语言中以C++最为复杂,C#次之,Java最单纯。但不管是复杂的C++还是单纯的Java我们都需要认真分析和考虑对象生命周期管理,实现合理的设计。
总结
本文介绍了对象间4种横向关系,并探讨了DI和创建对象两种设计方式适用的情形,最后探讨了DI注入方式的选择问题。文中错误和不足之处欢迎批评指正,也希望和对此话题感兴趣的朋友交流!
参考:
http://www.cnblogs.com/floodpeak/archive/2008/02/27/1083533.html