Annotation註解APT(三):依賴注入是什麼

阿新 • • 發佈：2019-01-30

引言

１編寫文件：通過程式碼裡標識的元資料生成文件，常用的有@param、@return等；
２程式碼分析：通過程式碼裡標識的元資料對程式碼進行分析獲取資訊，或生成描述檔案，甚至或是新的類定義。
３編譯檢查：通過程式碼裡標識的元資料讓編譯器能實現基本的編譯檢查。

除了上面基本的功能外，註解還有其它的用處，比如依賴注入，那麼依賴注入是什麼？為什麼要有依賴注入？

下面文章來源於網路．

IGame遊戲公司的故事

1.1 討論會

話說有一個叫IGame的遊戲公司，正在開發一款ARPG遊戲（動作&角色扮演類遊戲，如魔獸世界、夢幻西遊這一類的遊戲）。一般這類遊戲都有一個基本的功能，就是打怪（玩家攻擊怪物，藉此獲得經驗、虛擬貨幣和虛擬裝備），並且根據玩家角色所裝備的武器不同，攻擊效果也不同。這天，IGame公司的開發小組正在開會對打怪功能中的某一個功能點如何實現進行討論，他們面前的大螢幕上是這樣一份需求描述的ppt：
　　　　　　　這裡寫圖片描述

　　　　　　　各個開發人員，面對這份需求，展開了熱烈的討論，下面我們看看討論會上都發生了什麼。
　　　　　　　
1.2 實習生小李的實現方式
在經過一番討論後，專案組長Peter覺得有必要整理一下各方的意見，他首先詢問小李的看法。小李是某學校計算機系大三學生，對遊戲開發特別感興趣，目前是IGame公司的一名實習生。

經過短暫的思考，小李闡述了自己的意見：

“我認為，這個需求可以這麼實現。HP當然是怪物的一個屬性成員，而武器是角色的一個屬性成員，型別可以使字串，用於描述目前角色所裝備的武器。角色類有一個攻擊方法，以被攻擊怪物為引數，當實施一次攻擊時，攻擊方法被呼叫，而這個方法首先判斷當前角色裝備了什麼武器，然後據此對被攻擊怪物的HP進行操作，以產生不同效果。”

而在闡述完後，小李也飛快的在自己的電腦上寫了一個Demo，來演示他的想法，Demo程式碼如下。

Code：怪物

using System;   
using System.Collections.Generic;   
using System.Linq;   
using System.Text;   

namespace IGameLi   
{   
     /// <summary>   
     /// 怪物  
     /// </summary>  
     internal sealed class Monster  
     {  
         /// 
 <summary>  
         /// 怪物的名字  
         /// </summary>  
         public String Name { get; set; }  

         /// <summary>  
         /// 怪物的生命值  
         /// </summary>  
         public Int32 HP { get; set; }  

         public Monster(String name,Int32 hp)  
         {  
             this.Name = name;  
             this.HP = hp;  
         }  
     }  
 }

Code：角色

 using System;
 using System.Collections.Generic;
 using System.Linq;
 using System.Text;

 namespace IGameLi
 {
     /// <summary>
     /// 角色
     /// </summary>
     internal sealed class Role
     {
         private Random _random = new Random();

         /// <summary>
         /// 表示角色目前所持武器的字串
         /// </summary>
         public String WeaponTag { get; set; }

         /// <summary>
         /// 攻擊怪物
         /// </summary>
         /// <param name="monster">被攻擊的怪物</param>
         public void Attack(Monster monster)
         {
             if (monster.HP <= 0)
             {
                 Console.WriteLine("此怪物已死");
                 return;
             }

             if ("WoodSword" == this.WeaponTag)
             {
                 monster.HP -= 20;
                 if (monster.HP <= 0)
                 {
                     Console.WriteLine("攻擊成功！怪物" + monster.Name + "已死亡");
                 }
                 else
                 {
                     Console.WriteLine("攻擊成功！怪物" + monster.Name + "損失20HP");
                 }
             }
             else if ("IronSword" == this.WeaponTag)
             {
                 monster.HP -= 50;
                 if (monster.HP <= 0)
                 {
                     Console.WriteLine("攻擊成功！怪物" + monster.Name + "已死亡");
                 }
                 else
                 {
                     Console.WriteLine("攻擊成功！怪物" + monster.Name + "損失50HP");
                 }
             }
             else if ("MagicSword" == this.WeaponTag)
             {
                 Int32 loss = (_random.NextDouble() < 0.5) ? 100 : 200;
                 monster.HP -= loss;
                 if (200 == loss)
                 {
                     Console.WriteLine("出現暴擊！！！");
                 }

                 if (monster.HP <= 0)
                 {
                     Console.WriteLine("攻擊成功！怪物" + monster.Name + "已死亡");
                 }
                 else
                 {
                     Console.WriteLine("攻擊成功！怪物" + monster.Name + "損失" + loss + "HP");
                 }
             }
             else
             {
                 Console.WriteLine("角色手裡沒有武器，無法攻擊！");
             }
         }
     }
 }

Code：測試程式碼

using System;   
using System.Collections.Generic;   
using System.Linq;   
using System.Text;   

namespace IGameLi   
{   
    class Program   
    {  
         static void Main(string[] args)  
         {  
             //生成怪物  
             Monster monster1 = new Monster("小怪A", 50);  
             Monster monster2 = new Monster("小怪B", 50);  
             Monster monster3 = new Monster("關主", 200);  
            Monster monster4 = new Monster("最終Boss", 1000);  

             //生成角色  
             Role role = new Role();  

             //木劍攻擊  
             role.WeaponTag = "WoodSword";  
             role.Attack(monster1);  

             //鐵劍攻擊  
             role.WeaponTag = "IronSword";  
             role.Attack(monster2);  
             role.Attack(monster3);  

             //魔劍攻擊  
             role.WeaponTag = "MagicSword";  
             role.Attack(monster3);  
             role.Attack(monster4);  
             role.Attack(monster4);  
             role.Attack(monster4);  
             role.Attack(monster4);  
             role.Attack(monster4);  

             Console.ReadLine();  
         }  
     }  
 }

程式執行結果如下：
這裡寫圖片描述

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類圖，用於直觀表示他的思想:
這裡寫圖片描述

Peter讓小李按照小於的設計重構Demo，小李看了看小於的設計圖，很快完成。相關程式碼如下：

Code：IAttackStrategy介面

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace IGameLiAdv
7: {
8: internal interface IAttackStrategy
9: {
10: void AttackTarget(Monster monster);
11: }
12: }

Code：木劍

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace IGameLiAdv
7: {
8: internal sealed class WoodSword : IAttackStrategy
9: {
10: public void AttackTarget(Monster monster)
11: {
12: monster.Notify(20);
13: }
14: }
15: }

Code：鐵劍

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace IGameLiAdv
7: {
8: internal sealed class IronSword : IAttackStrategy
9: {
10: public void AttackTarget(Monster monster)
11: {
12: monster.Notify(50);
13: }
14: }
15: }

Code：魔劍

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace IGameLiAdv
7: {
8: internal sealed class MagicSword : IAttackStrategy
9: {
10: private Random _random = new Random();
11:
12: public void AttackTarget(Monster monster)
13: {
14: Int32 loss = (_random.NextDouble() < 0.5) ? 100 : 200;
15: if (200 == loss)
16: {
17: Console.WriteLine(“出現暴擊！！！”);
18: }
19: monster.Notify(loss);
20: }
21: }
22: }

Code：怪物

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace IGameLiAdv
7: {
8: ///
9: /// 怪物
10: ///
11: internal sealed class Monster
12: {
13: ///
14: /// 怪物的名字
15: ///
16: public String Name { get; set; }
17:
18: ///
19: /// 怪物的生命值
20: ///
21: private Int32 HP { get; set; }
22:
23: public Monster(String name,Int32 hp)
24: {
25: this.Name = name;
26: this.HP = hp;
27: }
28:
29: ///
30: /// 怪物被攻擊時，被呼叫的方法，用來處理被攻擊後的狀態更改
31: ///
32: /// 此次攻擊損失的HP
33: public void Notify(Int32 loss)
34: {
35: if (this.HP <= 0)
36: {
37: Console.WriteLine(“此怪物已死”);
38: return;
39: }
40:
41: this.HP -= loss;
42: if (this.HP <= 0)
43: {
44: Console.WriteLine(“怪物” + this.Name + “被打死”);
45: }
46: else
47: {
48: Console.WriteLine(“怪物” + this.Name + “損失” + loss + “HP”);
49: }
50: }
51: }
52: }

Code：角色

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace IGameLiAdv
7: {
8: ///
9: /// 角色
10: ///
11: internal sealed class Role
12: {
13: ///
14: /// 表示角色目前所持武器
15: ///
16: public IAttackStrategy Weapon { get; set; }
17:
18: ///
19: /// 攻擊怪物
20: ///
21: /// 被攻擊的怪物
22: public void Attack(Monster monster)
23: {
24: this.Weapon.AttackTarget(monster);
25: }
26: }
27: }

Code：測試程式碼

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace IGameLiAdv
7: {
8: class Program
9: {
10: static void Main(string[] args)
11: {
12: //生成怪物
13: Monster monster1 = new Monster(“小怪A”, 50);
14: Monster monster2 = new Monster(“小怪B”, 50);
15: Monster monster3 = new Monster(“關主”, 200);
16: Monster monster4 = new Monster(“最終Boss”, 1000);
17:
18: //生成角色
19: Role role = new Role();
20:
21: //木劍攻擊
22: role.Weapon = new WoodSword();
23: role.Attack(monster1);
24:
25: //鐵劍攻擊
26: role.Weapon = new IronSword();
27: role.Attack(monster2);
28: role.Attack(monster3);
29:
30: //魔劍攻擊
31: role.Weapon = new MagicSword();
32: role.Attack(monster3);
33: role.Attack(monster4);
34: role.Attack(monster4);
35: role.Attack(monster4);
36: role.Attack(monster4);
37: role.Attack(monster4);
38:
39: Console.ReadLine();
40: }
41: }
42: }

編譯執行以上程式碼，得到的執行結果與上一版本程式碼基本一致。

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方法接受一個具體的服務類例項為引數，並將它賦給服務類介面型別的資料成員。
這裡寫圖片描述
上圖展示了Setter注入的結構示意圖，客戶類ClientClass設定IServiceClass型別成員_serviceImpl，並設定Set_ServiceImpl方法作為注入點。Context會負責例項化一個具體的ServiceClass，然後注入到ClientClass裡。

下面給出Setter注入的示例程式碼。

Code：IServiceClass

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace SetterInjection
7: {
8: internal interface IServiceClass
9: {
10: String ServiceInfo();
11: }
12: }

Code：ServiceClassA

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace SetterInjection
7: {
8: internal class ServiceClassA : IServiceClass
9: {
10: public String ServiceInfo()
11: {
12: return “我是ServceClassA”;
13: }
14: }
15: }

Code：ServiceClassB

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace SetterInjection
7: {
8: internal class ServiceClassB : IServiceClass
9: {
10: public String ServiceInfo()
11: {
12: return “我是ServceClassB”;
13: }
14: }
15: }

Code：ClientClass

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace SetterInjection
7: {
8: internal class ClientClass
9: {
10: private IServiceClass _serviceImpl;
11:
12: public void Set_ServiceImpl(IServiceClass serviceImpl)
13: {
14: this._serviceImpl = serviceImpl;
15: }
16:
17: public void ShowInfo()
18: {
19: Console.WriteLine(_serviceImpl.ServiceInfo());
20: }
21: }
22: }

Code：Context

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace SetterInjection
7: {
8: class Program
9: {
10: static void Main(string[] args)
11: {
12: IServiceClass serviceA = new ServiceClassA();
13: IServiceClass serviceB = new ServiceClassB();
14: ClientClass client = new ClientClass();
15:
16: client.Set_ServiceImpl(serviceA);
17: client.ShowInfo();
18: client.Set_ServiceImpl(serviceB);
19: client.ShowInfo();
20: }
21: }
22: }

執行結果如下：
這裡寫圖片描述

3.1.2 構造注入

另外一種依賴注入方式，是通過客戶類的建構函式，向客戶類注入服務類例項。

構造注入（Constructor Injection）是指在客戶類中，設定一個服務類介面型別的資料成員，並以建構函式為注入點，這個建構函式接受一個具體的服務類例項為引數，並將它賦給服務類介面型別的資料成員。
這裡寫圖片描述
上圖是構造注入的示意圖，可以看出，與Setter注入很類似，只是注入點由Setter方法變成了構造方法。這裡要注意，由於構造注入只能在例項化客戶類時注入一次，所以一點注入，程式執行期間是沒法改變一個客戶類物件內的服務類例項的。

由於構造注入和Setter注入的IServiceClass，ServiceClassA和ServiceClassB是一樣的，所以這裡給出另外ClientClass類的示例程式碼。

Code：ClientClass

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace ConstructorInjection
7: {
8: internal class ClientClass
9: {
10: private IServiceClass _serviceImpl;
11:
12: public ClientClass(IServiceClass serviceImpl)
13: {
14: this._serviceImpl = serviceImpl;
15: }
16:
17: public void ShowInfo()
18: {
19: Console.WriteLine(_serviceImpl.ServiceInfo());
20: }
21: }
22: }

可以看到，唯一的變化就是建構函式取代了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元件的示例程式碼，完整程式碼請參考文末附上的完整源程式。

Code：按鈕介面

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace DependencyLocate
7: {
8: internal interface IButton
9: {
10: String ShowInfo();
11: }
12: }

Code：Windows風格按鈕

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace DependencyLocate
7: {
8: internal sealed class WindowsButton : IButton
9: {
10: public String Description { get; private set; }
11:
12: public WindowsButton()
13: {
14: this.Description = “Windows風格按鈕”;
15: }
16:
17: public String ShowInfo()
18: {
19: return this.Description;
20: }
21: }
22: }

Code：Mac風格按鈕

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace DependencyLocate
7: {
8: internal sealed class MacButton : IButton
9: {
10: public String Description { get; private set; }
11:
12: public MacButton()
13: {
14: this.Description = ” Mac風格按鈕”;
15: }
16:
17: public String ShowInfo()
18: {
19: return this.Description;
20: }
21: }
22: }

Code：工廠介面

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace DependencyLocate
7: {
8: internal interface IFactory
9: {
10: IWindow MakeWindow();
11:
12: IButton MakeButton();
13:
14: ITextBox MakeTextBox();
15: }
16: }

Code：Windows元件工廠

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace DependencyLocate
7: {
8: internal sealed class WindowsFactory : IFactory
9: {
10: public IWindow MakeWindow()
11: {
12: return new WindowsWindow();
13: }
14:
15: public IButton MakeButton()
16: {
17: return new WindowsButton();
18: }
19:
20: public ITextBox MakeTextBox()
21: {
22: return new WindowsTextBox();
23: }
24: }
25: }

Code：Mac元件工廠

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace DependencyLocate
7: {
8: internal sealed class MacFactory : IFactory
9: {
10: public IWindow MakeWindow()
11: {
12: return new MacWindow();
13: }
14:
15: public IButton MakeButton()
16: {
17: return new MacButton();
18: }
19:
20: public ITextBox MakeTextBox()
21: {
22: return new MacTextBox();
23: }
24: }
25: }

Code：獲取點

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5: using System.Xml;
6:
7: namespace DependencyLocate
8: {
9: internal static class FactoryContainer
10: {
11: public static IFactory factory { get; private set; }
12:
13: static FactoryContainer()
14: {
15: XmlDocument xmlDoc = new XmlDocument();
16: xmlDoc.Load(“http://www.cnblogs.com/Config.xml“);
17: XmlNode xmlNode = xmlDoc.ChildNodes[1].ChildNodes[0].ChildNodes[0];
18:
19: if (“Windows” == xmlNode.Value)
20: {
21: factory = new WindowsFactory();
22: }
23: else if (“Mac” == xmlNode.Value)
24: {
25: factory = new MacFactory();
26: }
27: else
28: {
29: throw new Exception(“Factory Init Error”);
30: }
31: }
32: }
33: }

Code：測試程式碼

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: namespace DependencyLocate
7: {
8: class Program
9: {
10: static void Main(string[] args)
11: {
12: IFactory factory = FactoryContainer.factory;
13: IWindow window = factory.MakeWindow();
14: Console.WriteLine(“建立 ” + window.ShowInfo());
15: IButton button = factory.MakeButton();
16: Console.WriteLine(“建立 ” + button.ShowInfo());
17: ITextBox textBox = factory.MakeTextBox();
18: Console.WriteLine(“建立 ” + textBox.ShowInfo());
19:
20: Console.ReadLine();
21: }
22:
}
23: }

這裡我們用XML作為配置檔案。配置檔案Config.xml如下：

<?xml version="1.0" encoding="utf-8" ?>   
 <config>   
     <factory>Mac</factory>   
 </config>

可以看到，這裡我們將配置設定為Mac風格，編譯執行上述程式碼，執行結果如下：
這裡寫圖片描述

現在，我們不動程式，僅僅將配置檔案中的“Mac”改為Windows，執行後結果如下：
這裡寫圖片描述

從執行結果看出，我們僅僅通過修改配置檔案，就改變了整個程式的行為（我們甚至沒有重新編譯程式），這就是多型性的威力，也是依賴注入效果。

本節共討論了三種基本的依賴注入類別，有關更多依賴注入類別和不同類別對比的知識，可以參考Martin Fowler的《Inversion of Control Containers and the Dependency Injection pattern》。

3.2 反射與依賴注入

回想上面Dependency Locate的例子，我們雖然使用了多型性和Abstract Factory，但對OCP貫徹的不夠徹底。在理解這點前，朋友們一定要注意潛在擴充套件在哪裡，潛在會出現擴充套件的地方是“新的元件系列”而不是“元件種類”，也就是說，這裡我們假設元件就三種，不會增加新的元件，但可能出現新的外觀系列，如需要加一套Ubuntu風格的元件，我們可以新增UbuntuWindow、UbuntuButton、UbuntuTextBox和UbuntuFactory，並分別實現相應介面，這是符合OCP的，因為這是擴充套件。但我們除了修改配置檔案，還要無可避免的修改FactoryContainer，需要加一個分支條件，這個地方破壞了OCP。依賴注入本身是沒有能力解決這個問題的，但如果語言支援反射機制（Reflection），則這個問題就迎刃而解。

我們想想，現在的難點是出在這裡：物件最終還是要通過“new”來例項化，而“new”只能例項化當前已有的類，如果未來有新類新增進來，必須修改程式碼。如果，我們能有一種方法，不是通過“new”，而是通過類的名字來例項化物件，那麼我們只要將類的名字作為配置項，就可以實現在不修改程式碼的情況下，載入未來才出現的類。所以，反射給了語言“預見未來”的能力，使得多型性和依賴注入的威力大增。

下面是引入反射機制後，對上面例子的改進：
這裡寫圖片描述
可以看出，引入反射機制後，結構簡單了很多，一個反射工廠代替了以前的一堆工廠，Factory Container也不需要了。而且以後有新元件系列加入時，反射工廠是不用改變的，只需改變配置檔案就可以完成。下面給出反射工廠和配置檔案的程式碼。

Code：反射工廠

1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5: using System.Reflection;
6: using System.Xml;
7:
8: namespace DependencyLocate
9: {
10: internal static class ReflectionFactory
11: {
12: private static String _windowType;
13: private static String _buttonType;
14: private static String _textBoxType;
15:
16: static ReflectionFactory()
17: {
18: XmlDocument xmlDoc = new XmlDocument();
19: xmlDoc.Load(“http://www.cnblogs.com/Config.xml“);
20: XmlNode xmlNode = xmlDoc.ChildNodes[1].ChildNodes[0];
21:
22: _windowType = xmlNode.ChildNodes[0].Value;
23: _buttonType = xmlNode.ChildNodes[1].Value;
24: _textBoxType = xmlNode.ChildNodes[2].Value;
25: }
26:
27: public static IWindow MakeWindow()
28: {
29: return Assembly.Load(“DependencyLocate”).CreateInstance(“DependencyLocate.” + _windowType) as IWindow;
30: }
31:
32: public static IButton MakeButton()
33: {
34: return Assembly.Load(“DependencyLocate”).CreateInstance(“DependencyLocate.” + _buttonType) as IButton;
35: }
36:
37: public static ITextBox MakeTextBox()
38: {
39: return Assembly.Load(“DependencyLocate”).CreateInstance(“DependencyLocate.” + _textBoxType) as ITextBox;
40: }
41: }
42: }

配置檔案如下：

<?xml version="1.0" encoding="utf-8" ?>
 <config>
     <window>MacWindow</window>
     <button>MacButton</button>
     <textBox>MacTextBox</textBox>
</config>

反射不僅可以與Dependency Locate結合，也可以與Setter Injection與Construtor Injection結合。反射機制的引入，降低了依賴注入結構的複雜度，使得依賴注入徹底符合OCP，併為通用依賴注入框架（如Spring.NET中的IoC部分、Unity等）的設計提供了可能性。

3.3 多型的活性與依賴注入

重要宣告：3.3節內容中諸多術語（包括但不限於“多型活性”、“高活多型性”、“中活多型性”、“低活多型性”、“多型時間空間穩定”）與諸多理論思想（包括但不限於“多型活性定義”、“根據活性分類多型”、“根據活性選擇依賴注入型別”）均為筆者原創，所以，特宣告以下兩點：一、由於筆者水平所限，不保證其完全正確性和嚴格性，與前面諸多成熟理論相比，請批判性閱讀；二、由於此節中諸多概念與思想理論已納入筆者論文素材範疇，作為筆者原創成果，受法律保護。任何單位和個人不得擅自將此節內容部分或全部抄襲、改造、重新敘述成文進行公開發表。否則，筆者保留追究法律責任的權利。

3.3.1 多型性的活性

這一節我們討論多型的活性及其與依賴注入型別選擇間密切的關係。

首先說明，“多型的活性”這個術語是我個人定義的，因為我沒有找到既有的概念名詞可以表達我的意思，所以就自己造了一個詞。這裡，某多型的活性是指被此多型隔離的變化所發生變化的頻繁程度，頻繁程度越高，則活性越強，反之亦然。

上文說過，多型性可以隔離變化，但是，不同的變化，發生的頻率是不一樣的，這就使得多型的活性有所差別，這種差別影響了依賴注入的型別選擇。

舉例來說，本文最開始提到的武器多型性，其活性非常高，因為在那個程式中，Role在一次執行中可能更換多次武器。而現在我們假設Role也實現了多型性，這是很可能的，因為在遊戲中，不同型別的角色（如暗夜精靈、牛頭人、矮人等）很多屬性和業務是想通的，所以很可能通過一個IRole或AbstractRole抽象類實現多型性，不過，Role在例項化後（一般在使用者登入成功後），是不會變化的，很少有遊戲允許同一個玩家在執行中變換Role型別，所以Role應該是一但例項化，就不會變化，但如果再例項化一個（如另一個玩家登入），則可能就變化了。最後，還有一種多型性是活性非常低的，如我們熟悉的資料訪問層多型性，即使我們實現了SQL Server、Oracle和Access等多種資料庫的訪問層，並實現了依賴注入，但幾乎遇不到程式執行著就改資料庫或短期內資料庫頻繁變動的情況。

以上不同的多型性，不但特徵不同，其目的一般也不同，總結如下：

高活多型性——指在客戶類例項執行期間，服務類可能會改變的多型性。

中活多型性——指在客戶類例項化後，服務類不會改變，但同一時間記憶體在的不同例項可能擁有不同型別的服務類。

低活多型性——指在客戶類例項化後，服務類不會改變，且同一時間內所有客戶類都擁有相同型別的服務類。

以上三種多型性，比較好的例子就是上文提到的武器多型性（高活）、角色多型性（中活）和資料訪問層多型性（低活）。另外，我們說一種多型性是空間穩定的，如果同一客戶類在同一時間內的所有例項都依賴相同型別的服務類，反之則叫做空間不穩定多型性。我們說一種多型性是時間穩定的，如果一個客戶類在例項化後，所以來的服務類不能再次更改，反之則叫做時間不穩定多型性。顯然，高活多型性時間和空間均不穩定；中活多型性是時間穩定的，但空間不穩定；低活多型性時間空間均穩定。

3.3.2 不同活性多型的依賴注入選擇

一般來說，高活多型性適合使用Setter注入。因為Setter注入最靈活，也是唯一允許在同一客戶類例項執行期間更改服務類的注入方式。並且這種注入一般由上下文環境通過Setter的引數指定服務類型別，方便靈活，適合頻繁變化的高活多型性。

對於中活多型性，則適合使用Constructor注入。因為Constructor注入也是由上下文環境通過Construtor的引數指定服務類型別，但一點客戶類例項化後，就不能進行再次注入，保證了其時間穩定性。

而對於低活多型性，則適合使用Dependency Locate並配合檔案配置進行依賴注入，或Setter、Constructor配合配置檔案注入，因為依賴源來自檔案，如果要更改服務類，則需要更改配置檔案，一則確保了低活多型性的時間和空間穩定性，二是更改配置檔案的方式方便於大規模服務類替換。（因為低活多型性一旦改變行為，往往規模很大，如替換整個資料訪問層，如果使用Setter和Construtor傳參，程式中需要改變的地方不計其數）

本質上，這種選擇是因為不同的依賴注入型別有著不同的穩定性，大家可以細細體會“活性”、“穩定性”和“依賴注入型別”之間密切的關係。

個人總結：所謂依賴注入的作用就是降低程式碼的耦合性，便於程式碼的擴充套件．

Annotation註解APT(三):依賴注入是什麼

引言

IGame遊戲公司的故事

Annotation註解APT(三):依賴注入是什麼

Annotation註解APT(五):注入框架ButterKnife

spring boot 學習(三) — 依賴注入 @Bean

Spring 註解實現Bean依賴注入之@Qualifier

Spring 註解實現Bean依賴注入之@Required

Spring學習（1）：控制反轉（IoC）和依賴注入（DI）的詳解以及註解（annotation）開發入門案例

【Annotation】使用自定義註解實現依賴注入

依賴注入的兩種常用方式(構造器和Setter)與注入內容(裝配資料)——Spring IOC/DI（三）

ASP.NET Core中使用GraphQL - 第三章依賴注入

Effective Java 第三版讀書筆記——條款5：使用依賴注入替代替代硬連線資源

Spring依賴注入（構造引數注入、集合，陣列屬性注入、XML自動注入，全註解配置）

.NET Core實戰專案之CMS 第三章入門篇-原始碼解析配置檔案及依賴注入

spring的依賴注入 -------基於註解方式

Spring基於註解的IOC的依賴注入

spring依賴注入: 註解注入

spring下應用@Resource, @Autowired 和 @Inject註解進行依賴注入的差異

Spring原始碼分析（三）（IoC容器的依賴注入）（2）

Spring原始碼分析（三）（IoC容器的依賴注入）（1）

Spring Boot2.x-05Spring Boot基礎-使用註解完成依賴注入

依賴注入框架Dagger2—2.各註解用法

Annotation註解APT(三):依賴注入是什麼

引言

IGame遊戲公司的故事

相關推薦