依赖注入那些事儿(转载【强烈推荐】)

设计模式 前端之家
前端之家收集整理的这篇文章主要介绍了依赖注入那些事儿(转载【强烈推荐】)，前端之家小编觉得挺不错的，现在分享给大家，也给大家做个参考。


目录

目录

1 IGame游戏公司的故事

1.1 讨论会

1.2 实习生小李的实现方法

1.3 架构师的建议

1.4 小李的小结

2 探究依赖注入

2.1 故事的启迪

2.2 正式定义依赖注入

3 依赖注入那些事儿

3.1 依赖注入的类别

3.1.1 Setter注入

3.1.2 Construtor注入

3.1.3 依赖获取

3.2 反射与依赖注入

3.3 多态的活性与依赖注入

3.3.1 多态性的活性

3.3.2 不同活性多态性依赖注入的选择

4 IoC Container

4.1 IoC Container出现的必然性

4.2 IoC Container的分类

4.2.1 重量级IoC Container

4.2.2 轻量级IoC Container

4.3 .NET平台上典型IoC Container推介

4.3.1 Spring.NET

4.3.2 Unity

参考文献

1 IGame游戏公司的故事

1.1 讨论会

话说有一个叫IGame的游戏公司，正在开发一款ARPG游戏（动作&角色扮演类游戏，如魔兽世界、梦幻西游这一类的游戏）。一般这类游戏都有一个基本的功能，就是打怪（玩家攻击怪物，借此获得经验、虚拟货币和虚拟装备），并且根据玩家角色所装备的武器不同，攻击效果也不同。这天，IGame公司的开发小组正在开会对打怪功能中的某一个功能点如何实现进行讨论，他们面前的大屏幕上是这样一份需求描述的ppt：

图1.1 需求描述ppt

各个开发人员，面对这份需求，展开了热烈的讨论，下面我们看看讨论会上都发生了什么。

1.2 实习生小李的实现方式

在经过一番讨论后，项目组长Peter觉得有必要整理一下各方的意见，他首先询问小李的看法。小李是某学校计算机系大三学生，对游戏开发特别感兴趣，目前是IGame公司的一名实习生。

经过短暂的思考，小李阐述了自己的意见：

“我认为，这个需求可以这么实现。HP当然是怪物的一个属性成员，而武器是角色的一个属性成员，类型可以使字符串，用于描述目前角色所装备的武器。角色类有一个攻击方法，以被攻击怪物为参数，当实施一次攻击时，攻击方法被调用，而这个方法首先判断当前角色装备了什么武器，然后据此对被攻击怪物的HP进行操作，以产生不同效果。”

而在阐述完后，小李也飞快的在自己的电脑上写了一个Demo，来演示他的想法，Demo代码如下。

?
using System;
System.Collections.Generic;
System.Linq;
System.Text;
namespace IGameLi
{
/// <summary>
/// 怪物
/// </summary>
internal sealed class Monster
{
/// <summary>
/// 怪物的名字
/// </summary>
public String Name { get ; set ; }
/// <summary>
/// 怪物的生命值
/// </summary>
Int32 HP { ; }
Monster(String name,Int32 hp)
{
this .Name = name;
.HP = hp;
}
}
}
View Code

程序运行结果如下：

图1.2 小李程序的运行结果

1.3 架构师的建议

小李阐述完自己的想法并演示了Demo后，项目组长Peter首先肯定了小李的思考能力、编程能力以及初步的面向对象分析与设计的思想，并承认小李的程序正确完成了需求中的功能。但同时，Peter也指出小李的设计存在一些问题，他请小于讲一下自己的看法。

小于是一名有五年软件架构经验的架构师，对软件架构、设计模式和面向对象思想有较深入的认识。他向Peter点了点头，发表了自己的看法：

“小李的思考能力是不错的，有着基本的面向对象分析设计能力，并且程序正确完成了所需要的功能。不过，这里我想从架构角度，简要说一下我认为这个设计中存在的问题。

首先，小李设计的Role类的Attack方法很长，并且方法中有一个冗长的if…else结构，且每个分支的代码的业务逻辑很相似，只是很少的地方不同。

再者，我认为这个设计比较大的一个问题是，违反了OCP原则。在这个设计中，如果以后我们增加一个新的武器，如倚天剑，每次攻击损失500HP，那么，我们就要打开Role，修改Attack方法。而我们的代码应该是对修改关闭的，当有新武器加入的时候，应该使用扩展完成，避免修改已有代码。

一般来说，当一个方法里面出现冗长的if…else或switch…case结构，且每个分支代码业务相似时，往往预示这里应该引入多态性来解决问题。而这里，如果把不同武器攻击看成一个策略，那么引入策略模式（Strategy Pattern）是明智的选择。

最后说一个小的问题，被攻击后，减HP、死亡判断等都是怪物的职责，这里放在Role中有些不当。”

Tip：OCP原则，即开放关闭原则，指设计应该对扩展开放，对修改关闭。

Tip：策略模式，英文名Strategy Pattern，指定义算法族，分别封装起来，让他们之间可以相互替换，此模式使得算法的变化独立于客户。

小于边说，边画了一幅UML类图，用于直观表示他的思想。

图1.3 小于的设计

Peter让小李按照小于的设计重构Demo，小李看了看小于的设计图，很快完成。相关代码如下：

@H_365_301@编译运行以上代码，得到的运行结果与上一版本代码基本一致。

1.4 小李的小结

Peter显然对改进后的代码比较满意，他让小李对照两份设计和代码，进行一个小结。小李简略思考了一下，并结合小于对一次设计指出的不足，说道：

“我认为，改进后的代码有如下优点：

第一，虽然类的数量增加了，但是每个类中方法的代码都非常短，没有了以前Attack方法那种很长的方法，也没有了冗长的if…else，代码结构变得很清晰。

第二，类的职责更明确了。在第一个设计中，Role不但负责攻击，还负责给怪物减少HP和判断怪物是否已死。这明显不应该是Role的职责，改进后的代码将这两个职责移入Monster内，使得职责明确，提高了类的内聚性。

第三，引入Strategy模式后，不但消除了重复性代码，更重要的是，使得设计符合了OCP。如果以后要加一个新武器，只要新建一个类，实现IAttackStrategy接口，当角色需要装备这个新武器时，客户代码只要实例化一个新武器类，并赋给Role的Weapon成员就可以了，已有的Role和Monster代码都不用改动。这样就实现了对扩展开发，对修改关闭。”

Peter和小于听后都很满意，认为小李总结的非常出色。

IGame公司的讨论会还在进行着，内容是非常精彩，不过我们先听到这里，因为，接下来，我们要对其中某些问题进行一点探讨。别忘了，本文的主题可是依赖注入，这个主角还没登场呢！让主角等太久可不好。

2 探究依赖注入

2.1 故事的启迪

我们现在静下心来，再回味一下刚才的故事。因为，这个故事里面隐藏着依赖注入的出现原因。我说过不只一次，想真正认清一个事物，不能只看“它是什么？什么样子？”，而应该先弄清楚“它是怎么来的？是什么样的需求和背景促使了它的诞生？它被创造出来是做什么用的？”。

回想上面的故事。刚开始，主要需求是一个打怪的功能。小李做了一个初步面向对象的设计：抽取领域场景中的实体（怪物、角色等），封装成类，并为各个类赋予属性与方法，最后通过类的交互完成打怪功能，这应该算是面向对象设计的初级阶段。

在小李的设计基础上，架构师小于指出了几点不足，如不符合OCP，职责划分不明确等等，并根据情况引入策略模式。这是更高层次的面向对象设计。其实就核心来说，小于只做了一件事：利用多态性，隔离变化。它清楚认识到，这个打怪功能中，有些业务逻辑是不变的，如角色攻击怪物，怪物减少HP，减到0怪物就会死；而变化的仅仅是不同的角色持有不同武器时，每次攻击的效用不一样。于是他的架构，本质就是把变化的部分和不变的部分隔离开，使得变化部分发生变化时，不变部分不受影响。

我们再仔细看看小于的设计图，这样设计后，有个基本的问题需要解决：现在Role不依赖具体武器，而仅仅依赖一个IAttackStrategy接口，接口是不能实例化的，虽然Role的Weapon成员类型定义为IAttackStrategy，但最终还是会被赋予一个实现了IAttackStrategy接口的具体武器，并且随着程序进展，一个角色会装备不同的武器，从而产生不同的效用。赋予武器的职责，在Demo中是放在了测试代码里。

这里，测试代码实例化一个具体的武器，并赋给Role的Weapon成员的过程，就是依赖注入！这里要清楚，依赖注入其实是一个过程的称谓！

2.2 正式定义依赖注入

下面，用稍微正式一点的语言，定义依赖注入产生的背景缘由和依赖注入的含义。在读的过程中，读者可以结合上面的例子进行理解。

依赖注入产生的背景：

随着面向对象分析与设计的发展，一个良好的设计，核心原则之一就是将变化隔离，使得变化部分发生变化时，不变部分不受影响（这也是OCP的目的）。为了做到这一点，要利用面向对象中的多态性，使用多态性后，客户类不再直接依赖服务类，而是依赖于一个抽象的接口，这样，客户类就不能在内部直接实例化具体的服务类。但是，客户类在运作中又客观需要具体的服务类提供服务，因为接口是不能实例化去提供服务的。就产生了“客户类不准实例化具体服务类”和“客户类需要具体服务类”这样一对矛盾。为了解决这个矛盾，开发人员提出了一种模式：客户类（如上例中的Role）定义一个注入点（Public成员Weapon），用于服务类（实现IAttackStrategy的具体类，如WoodSword、IronSword和MagicSword，也包括以后加进来的所有实现IAttackStrategy的新类）的注入，而客户类的客户类（Program，即测试代码）负责根据情况，实例化服务类，注入到客户类中，从而解决了这个矛盾。

依赖注入的正式定义：

依赖注入（Dependency Injection），是这样一个过程：由于某客户类只依赖于服务类的一个接口，而不依赖于具体服务类，所以客户类只定义一个注入点。在程序运行过程中，客户类不直接实例化具体服务类实例，而是客户类的运行上下文环境或专门组件负责实例化服务类，然后将其注入到客户类中，保证客户类的正常运行。

3 依赖注入那些事儿

上面我们从需求背景的角度，讲述了依赖注入的来源和定义。但是，如果依赖注入仅仅就只有这么点东西，那也没有什么值得讨论的了。但是，上面讨论的仅仅是依赖注入的内涵，其外延还是非常广泛的，从依赖注入衍生出了很多相关的概念与技术，下面我们讨论一下依赖注入的“那些事儿”。

3.1 依赖注入的类别

依赖注入有很多种方法，上面看到的例子中，只是其中的一种，下面分别讨论不同的依赖注入类型。

3.1.1 Setter注入

第一种依赖注入的方式，就是Setter注入，上面的例子中，将武器注入Role就是Setter注入。正式点说：

Setter注入（Setter Injection）是指在客户类中，设置一个服务类接口类型的数据成员，并设置一个Set方法作为注入点，这个Set方法接受一个具体的服务类实例为参数，并将它赋给服务类接口类型的数据成员。

图3.1 Setter注入示意

上图展示了Setter注入的结构示意图，客户类ClientClass设置IServiceClass类型成员_serviceImpl，并设置Set_ServiceImpl方法作为注入点。Context会负责实例化一个具体的ServiceClass，然后注入到ClientClass里。

下面给出Setter注入的示例代码。

@H_365_301@运行结果如下：

图3.2 Setter注入运行结果

3.1.2 构造注入

另外一种依赖注入方式，是通过客户类的构造函数，向客户类注入服务类实例。

构造注入（Constructor Injection）是指在客户类中，设置一个服务类接口类型的数据成员，并以构造函数为注入点，这个构造函数接受一个具体的服务类实例为参数，并将它赋给服务类接口类型的数据成员。

图3.3 构造注入示意

图3.3是构造注入的示意图，可以看出，与Setter注入很类似，只是注入点由Setter方法变成了构造方法。这里要注意，由于构造注入只能在实例化客户类时注入一次，所以一点注入，程序运行期间是没法改变一个客户类对象内的服务类实例的。

由于构造注入和Setter注入的IServiceClass，ServiceClassA和ServiceClassB是一样的，所以这里给出另外ClientClass类的示例代码。

@H_365_301@可以看到，唯一的变化就是构造函数取代了Set_ServiceImpl方法，成为了注入点。

3.1.3 依赖获取

上面提到的注入方式，都是客户类被动接受所依赖的服务类，这也符合“注入”这个词。不过还有一种方法，可以和依赖注入达到相同的目的，就是依赖获取。

依赖获取（Dependency Locate）是指在系统中提供一个获取点，客户类仍然依赖服务类的接口。当客户类需要服务类时，从获取点主动取得指定的服务类，具体的服务类类型由获取点的配置决定。

可以看到，这种方法变被动为主动，使得客户类在需要时主动获取服务类，而将多态性的实现封装到获取点里面。获取点可以有很多种实现，也许最容易想到的就是建立一个Simple Factory作为获取点，客户类传入一个指定字符串，以获取相应服务类实例。如果所依赖的服务类是一系列类，那么依赖获取一般利用Abstract Factory模式构建获取点，然后，将服务类多态性转移到工厂的多态性上，而工厂的类型依赖一个外部配置，如XML文件。

不过，不论使用Simple Factory还是Abstract Factory，都避免不了判断服务类类型或工厂类型，这样系统中总要有一个地方存在不符合OCP的if…else或switch…case结构，这种缺陷是Simple Factory和Abstract Factory以及依赖获取本身无法消除的，而在某些支持反射的语言中（如C#），通过将反射机制的引入彻底解决了这个问题（后面讨论）。

下面给一个具体的例子，现在我们假设有个程序，既可以使用Windows风格外观，又可以使用Mac风格外观，而内部业务是一样的。

图3.4 依赖获取示意

上图乍看有点复杂，不过如果读者熟悉Abstract Factory模式，应该能很容易看懂，这就是Abstract Factory在实际中的一个应用。这里的Factory Container作为获取点，是一个静态类，它的“Type构造函数”依据外部的XML配置文件，决定实例化哪个工厂。下面还是来看示例代码。由于不同组件的代码是相似的，这里只给出Button组件的示例代码，完整代码请参考文末附上的完整源程序。

这里我们用XML作为配置文件。配置文件Config.xml如下：