生活随笔
收集整理的這篇文章主要介紹了
依赖注入 这样的坑游戏编程要谨慎
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
1 IGame游戲公司的故事
1.1 討論會
話說有一個叫IGame的游戲公司，正在開發(fā)一款A(yù)RPG游戲（動作&角色扮演類游戲，如魔獸世界、夢幻西游這一類的游戲）。一般這類游戲都有一個基本的功能，就是打怪（玩家攻擊怪物，借此獲得經(jīng)驗、虛擬貨幣和虛擬裝備），并且根據(jù)玩家角色所裝備的武器不同，攻擊效果也不同。這天，IGame公司的開發(fā)小組正在開會對打怪功能中的某一個功能點如何實現(xiàn)進行討論，他們面前的大屏幕上是這樣一份需求描述的ppt：
?
圖1.1 需求描述ppt
各個開發(fā)人員，面對這份需求，展開了熱烈的討論，下面我們看看討論會上都發(fā)生了什么。
1.2 實習(xí)生小李的實現(xiàn)方式
在經(jīng)過一番討論后，項目組長Peter覺得有必要整理一下各方的意見，他首先詢問小李的看法。小李是某學(xué)校計算機系大三學(xué)生，對游戲開發(fā)特別感興趣，目前是IGame公司的一名實習(xí)生。
經(jīng)過短暫的思考，小李闡述了自己的意見：
“我認為，這個需求可以這么實現(xiàn)。HP當然是怪物的一個屬性成員，而武器是角色的一個屬性成員，類型可以使字符串，用于描述目前角色所裝備的武器。角色類有一個攻擊方法，以被攻擊怪物為參數(shù)，當實施一次攻擊時，攻擊方法被調(diào)用，而這個方法首先判斷當前角色裝備了什么武器，然后據(jù)此對被攻擊怪物的HP進行操作，以產(chǎn)生不同效果。”
而在闡述完后，小李也飛快的在自己的電腦上寫了一個Demo，來演示他的想法，Demo代碼如下。
?
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;? ?? ???}? ? }} 復(fù)制代碼
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("出現(xiàn)暴擊！！！");? ?? ?? ?? ?? ? }? ?? ?? ?? ?? ?? ? if (monster.HP <= 0)? ?? ?? ?? ?? ? {? ?? ?? ?? ?? ?? ???Console.WriteLine("攻擊成功！怪物" + monster.Name + "已死亡");? ?? ?? ?? ?? ? }? ?? ?? ?? ?? ? else? ?? ?? ?? ?? ? {? ?? ?? ?? ?? ?? ???Console.WriteLine("攻擊成功！怪物" + monster.Name + "損失" + loss + "HP");? ?? ?? ?? ?? ? }? ?? ?? ?? ?}? ?? ?? ?? ?else? ?? ?? ?? ?{? ?? ?? ?? ?? ? Console.WriteLine("角色手里沒有武器，無法攻擊！");? ?? ?? ?? ?}? ?? ???}? ? }} 復(fù)制代碼
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("關(guān)主", 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();? ?? ???}? ? }} 復(fù)制代碼
程序運行結(jié)果如下：
?
圖1.2 小李程序的運行結(jié)果
1.3 架構(gòu)師的建議
小李闡述完自己的想法并演示了Demo后，項目組長Peter首先肯定了小李的思考能力、編程能力以及初步的面向?qū)ο蠓治雠c設(shè)計的思想，并承認小李的程序正確完成了需求中的功能。但同時，Peter也指出小李的設(shè)計存在一些問題，他請小于講一下自己的看法。
小于是一名有五年軟件架構(gòu)經(jīng)驗的架構(gòu)師，對軟件架構(gòu)、設(shè)計模式和面向?qū)ο笏枷胗休^深入的認識。他向Peter點了點頭，發(fā)表了自己的看法：
“小李的思考能力是不錯的，有著基本的面向?qū)ο蠓治鲈O(shè)計能力，并且程序正確完成了所需要的功能。不過，這里我想從架構(gòu)角度，簡要說一下我認為這個設(shè)計中存在的問題。
首先，小李設(shè)計的Role類的Attack方法很長，并且方法中有一個冗長的if…else結(jié)構(gòu)，且每個分支的代碼的業(yè)務(wù)邏輯很相似，只是很少的地方不同。
再者，我認為這個設(shè)計比較大的一個問題是，違反了OCP原則。在這個設(shè)計中，如果以后我們增加一個新的武器，如倚天劍，每次攻擊損失500HP，那么，我們就要打開Role，修改Attack方法。而我們的代碼應(yīng)該是對修改關(guān)閉的，當有新武器加入的時候，應(yīng)該使用擴展完成，避免修改已有代碼。
一般來說，當一個方法里面出現(xiàn)冗長的if…else或switch…case結(jié)構(gòu)，且每個分支代碼業(yè)務(wù)相似時，往往預(yù)示這里應(yīng)該引入多態(tài)性來解決問題。而這里，如果把不同武器攻擊看成一個策略，那么引入策略模式（Strategy Pattern）是明智的選擇。
最后說一個小的問題，被攻擊后，減HP、死亡判斷等都是怪物的職責，這里放在Role中有些不當。”
Tip：OCP原則，即開放關(guān)閉原則，指設(shè)計應(yīng)該對擴展開放，對修改關(guān)閉。
Tip：策略模式，英文名Strategy Pattern，指定義算法族，分別封裝起來，讓他們之間可以相互替換，此模式使得算法的變化獨立于客戶。
小于邊說，邊畫了一幅UML類圖，用于直觀表示他的思想。
?
圖1.3 小于的設(shè)計
Peter讓小李按照小于的設(shè)計重構(gòu)Demo，小李看了看小于的設(shè)計圖，很快完成。相關(guān)代碼如下：
?
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace IGameLiAdv{? ? internal interface IAttackStrategy? ? {? ?? ???void AttackTarget(Monster monster);? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace IGameLiAdv{? ? internal sealed class WoodSword : IAttackStrategy? ? {? ?? ???public void AttackTarget(Monster monster)? ?? ???{? ?? ?? ?? ?monster.Notify(20);? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace IGameLiAdv{? ? internal sealed class IronSword : IAttackStrategy? ? {? ?? ???public void AttackTarget(Monster monster)? ?? ???{? ?? ?? ?? ?monster.Notify(50);? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace IGameLiAdv{? ? internal sealed class MagicSword : IAttackStrategy? ? {? ?? ???private Random _random = new Random();? ?? ?? ???public void AttackTarget(Monster monster)? ?? ???{? ?? ?? ?? ?Int32 loss = (_random.NextDouble() < 0.5) ? 100 : 200;? ?? ?? ?? ?if (200 == loss)? ?? ?? ?? ?{? ?? ?? ?? ?? ? Console.WriteLine("出現(xiàn)暴擊！！！");? ?? ?? ?? ?}? ?? ?? ?? ?monster.Notify(loss);? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace IGameLiAdv{? ?/// <summary>? ?/// 怪物? ?/// </summary>? ? internal sealed class Monster? ? {? ?? ???/// <summary>? ?? ???/// 怪物的名字? ?? ???/// </summary>? ?? ???public String Name { get; set; }? ?? ?? ???/// <summary>? ?? ???/// 怪物的生命值? ?? ???/// </summary>? ?? ???private Int32 HP { get; set; }? ?? ?? ???public Monster(String name,Int32 hp)? ?? ???{? ?? ?? ?? ?this.Name = name;? ?? ?? ?? ?this.HP = hp;? ?? ???}? ?? ?? ???/// <summary>? ?? ???/// 怪物被攻擊時，被調(diào)用的方法，用來處理被攻擊后的狀態(tài)更改? ?? ???/// </summary>? ?? ???/// <param name="loss">此次攻擊損失的HP</param>? ?? ???public void Notify(Int32 loss)? ?? ???{? ?? ?? ?? ?if (this.HP <= 0)? ?? ?? ?? ?{? ?? ?? ?? ?? ? Console.WriteLine("此怪物已死");? ?? ?? ?? ?? ? return;? ?? ?? ?? ?}? ?? ?? ?? ?? ?this.HP -= loss;? ?? ?? ?? ?if (this.HP <= 0)? ?? ?? ?? ?{? ?? ?? ?? ?? ? Console.WriteLine("怪物" + this.Name + "被打死");? ?? ?? ?? ?}? ?? ?? ?? ?else? ?? ?? ?? ?{? ?? ?? ?? ?? ? Console.WriteLine("怪物" + this.Name + "損失" + loss + "HP");? ?? ?? ?? ?}? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace IGameLiAdv{? ?/// <summary>? ?/// 角色? ?/// </summary>? ? internal sealed class Role? ? {? ?? ???/// <summary>? ?? ???/// 表示角色目前所持武器? ?? ???/// </summary>? ?? ???public IAttackStrategy Weapon { get; set; }? ?? ?? ???/// <summary>? ?? ???/// 攻擊怪物? ?? ???/// </summary>? ?? ???/// <param name="monster">被攻擊的怪物</param>? ?? ???public void Attack(Monster monster)? ?? ???{? ?? ?? ?? ?this.Weapon.AttackTarget(monster);? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace IGameLiAdv{? ? class Program? ? {? ?? ???static void Main(string[] args)? ?? ???{? ?? ?? ?? ?//生成怪物? ?? ?? ?? ?Monster monster1 = new Monster("小怪A", 50);? ?? ?? ?? ?Monster monster2 = new Monster("小怪B", 50);? ?? ?? ?? ?Monster monster3 = new Monster("關(guān)主", 200);? ?? ?? ?? ?Monster monster4 = new Monster("最終Boss", 1000);? ?? ?? ?? ?? ?//生成角色? ?? ?? ?? ?Role role = new Role();? ?? ?? ?? ?? ?//木劍攻擊? ?? ?? ?? ?role.Weapon = new WoodSword();? ?? ?? ?? ?role.Attack(monster1);? ?? ?? ?? ?? ?//鐵劍攻擊? ?? ?? ?? ?role.Weapon = new IronSword();? ?? ?? ?? ?role.Attack(monster2);? ?? ?? ?? ?role.Attack(monster3);? ?? ?? ?? ?? ?//魔劍攻擊? ?? ?? ?? ?role.Weapon = new MagicSword();? ?? ?? ?? ?role.Attack(monster3);? ?? ?? ?? ?role.Attack(monster4);? ?? ?? ?? ?role.Attack(monster4);? ?? ?? ?? ?role.Attack(monster4);? ?? ?? ?? ?role.Attack(monster4);? ?? ?? ?? ?role.Attack(monster4);? ?? ?? ?? ?? ?Console.ReadLine();? ?? ???}? ? }} 復(fù)制代碼
編譯運行以上代碼，得到的運行結(jié)果與上一版本代碼基本一致。
1.4 小李的小結(jié)
Peter顯然對改進后的代碼比較滿意，他讓小李對照兩份設(shè)計和代碼，進行一個小結(jié)。小李簡略思考了一下，并結(jié)合小于對一次設(shè)計指出的不足，說道：
“我認為，改進后的代碼有如下優(yōu)點：
第一，雖然類的數(shù)量增加了，但是每個類中方法的代碼都非常短，沒有了以前Attack方法那種很長的方法，也沒有了冗長的if…else，代碼結(jié)構(gòu)變得很清晰。
第二，類的職責更明確了。在第一個設(shè)計中，Role不但負責攻擊，還負責給怪物減少HP和判斷怪物是否已死。這明顯不應(yīng)該是Role的職責，改進后的代碼將這兩個職責移入Monster內(nèi)，使得職責明確，提高了類的內(nèi)聚性。
第三，引入Strategy模式后，不但消除了重復(fù)性代碼，更重要的是，使得設(shè)計符合了OCP。如果以后要加一個新武器，只要新建一個類，實現(xiàn)IAttackStrategy接口，當角色需要裝備這個新武器時，客戶代碼只要實例化一個新武器類，并賦給Role的Weapon成員就可以了，已有的Role和Monster代碼都不用改動。這樣就實現(xiàn)了對擴展開發(fā)，對修改關(guān)閉。”
Peter和小于聽后都很滿意，認為小李總結(jié)的非常出色。
IGame公司的討論會還在進行著，內(nèi)容是非常精彩，不過我們先聽到這里，因為，接下來，我們要對其中某些問題進行一點探討。別忘了，本文的主題可是依賴注入，這個主角還沒登場呢！讓主角等太久可不好。
2 探究依賴注入
2.1 故事的啟迪
我們現(xiàn)在靜下心來，再回味一下剛才的故事。因為，這個故事里面隱藏著依賴注入的出現(xiàn)原因。我說過不只一次，想真正認清一個事物，不能只看“它是什么？什么樣子？”，而應(yīng)該先弄清楚“它是怎么來的？是什么樣的需求和背景促使了它的誕生？它被創(chuàng)造出來是做什么用的？”。
回想上面的故事。剛開始，主要需求是一個打怪的功能。小李做了一個初步面向?qū)ο蟮脑O(shè)計：抽取領(lǐng)域場景中的實體（怪物、角色等），封裝成類，并為各個類賦予屬性與方法，最后通過類的交互完成打怪功能，這應(yīng)該算是面向?qū)ο笤O(shè)計的初級階段。
在小李的設(shè)計基礎(chǔ)上，架構(gòu)師小于指出了幾點不足，如不符合OCP，職責劃分不明確等等，并根據(jù)情況引入策略模式。這是更高層次的面向?qū)ο笤O(shè)計。其實就核心來說，小于只做了一件事：利用多態(tài)性，隔離變化。它清楚認識到，這個打怪功能中，有些業(yè)務(wù)邏輯是不變的，如角色攻擊怪物，怪物減少HP，減到0怪物就會死；而變化的僅僅是不同的角色持有不同武器時，每次攻擊的效用不一樣。于是他的架構(gòu)，本質(zhì)就是把變化的部分和不變的部分隔離開，使得變化部分發(fā)生變化時，不變部分不受影響。
我們再仔細看看小于的設(shè)計圖，這樣設(shè)計后，有個基本的問題需要解決：現(xiàn)在Role不依賴具體武器，而僅僅依賴一個IAttackStrategy接口，接口是不能實例化的，雖然Role的Weapon成員類型定義為IAttackStrategy，但最終還是會被賦予一個實現(xiàn)了IAttackStrategy接口的具體武器，并且隨著程序進展，一個角色會裝備不同的武器，從而產(chǎn)生不同的效用。賦予武器的職責，在Demo中是放在了測試代碼里。
這里，測試代碼實例化一個具體的武器，并賦給Role的Weapon成員的過程，就是依賴注入！這里要清楚，依賴注入其實是一個過程的稱謂！
2.2 正式定義依賴注入
下面，用稍微正式一點的語言，定義依賴注入產(chǎn)生的背景緣由和依賴注入的含義。在讀的過程中，讀者可以結(jié)合上面的例子進行理解。
依賴注入產(chǎn)生的背景：
隨著面向?qū)ο蠓治雠c設(shè)計的發(fā)展，一個良好的設(shè)計，核心原則之一就是將變化隔離，使得變化部分發(fā)生變化時，不變部分不受影響（這也是OCP的目的）。為了做到這一點，要利用面向?qū)ο笾械亩鄳B(tài)性，使用多態(tài)性后，客戶類不再直接依賴服務(wù)類，而是依賴于一個抽象的接口，這樣，客戶類就不能在內(nèi)部直接實例化具體的服務(wù)類。但是，客戶類在運作中又客觀需要具體的服務(wù)類提供服務(wù)，因為接口是不能實例化去提供服務(wù)的。就產(chǎn)生了“客戶類不準實例化具體服務(wù)類”和“客戶類需要具體服務(wù)類”這樣一對矛盾。為了解決這個矛盾，開發(fā)人員提出了一種模式：客戶類（如上例中的Role）定義一個注入點（Public成員Weapon），用于服務(wù)類（實現(xiàn)IAttackStrategy的具體類，如WoodSword、IronSword和MagicSword，也包括以后加進來的所有實現(xiàn)IAttackStrategy的新類）的注入，而客戶類的客戶類（Program，即測試代碼）負責根據(jù)情況，實例化服務(wù)類，注入到客戶類中，從而解決了這個矛盾。
依賴注入的正式定義：
依賴注入（Dependency Injection），賣手機游戲是這樣一個過程：由于某客戶類只依賴于服務(wù)類的一個接口，而不依賴于具體服務(wù)類，所以客戶類只定義一個注入點。在程序運行過程中，客戶類不直接實例化具體服務(wù)類實例，而是客戶類的運行上下文環(huán)境或?qū)ｉT組件負責實例化服務(wù)類，然后將其注入到客戶類中，保證客戶類的正常運行。
3 依賴注入那些事兒
上面我們從需求背景的角度，講述了依賴注入的來源和定義。但是，如果依賴注入僅僅就只有這么點東西，那也沒有什么值得討論的了。但是，上面討論的僅僅是依賴注入的內(nèi)涵，其外延還是非常廣泛的，從依賴注入衍生出了很多相關(guān)的概念與技術(shù)，下面我們討論一下依賴注入的“那些事兒”。
3.1 依賴注入的類別
依賴注入有很多種方法，上面看到的例子中，只是其中的一種，下面分別討論不同的依賴注入類型。
3.1.1 Setter注入
第一種依賴注入的方式，就是Setter注入，上面的例子中，將武器注入Role就是Setter注入。正式點說：
Setter注入（Setter Injection）是指在客戶類中，設(shè)置一個服務(wù)類接口類型的數(shù)據(jù)成員，并設(shè)置一個Set方法作為注入點，這個Set方法接受一個具體的服務(wù)類實例為參數(shù)，并將它賦給服務(wù)類接口類型的數(shù)據(jù)成員。
圖3.1 Setter注入示意
上圖展示了Setter注入的結(jié)構(gòu)示意圖，客戶類ClientClass設(shè)置IServiceClass類型成員_serviceImpl，并設(shè)置Set_ServiceImpl方法作為注入點。Context會負責實例化一個具體的ServiceClass，然后注入到ClientClass里。
下面給出Setter注入的示例代碼。
?
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace SetterInjection{? ? internal interface IServiceClass? ? {? ?? ???String ServiceInfo();? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace SetterInjection{? ? internal class ServiceClassA : IServiceClass? ? {? ?? ???public String ServiceInfo()? ?? ???{? ?? ?? ?? ?return "我是ServceClassA";? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace SetterInjection{? ? internal class ServiceClassB : IServiceClass? ? {? ?? ???public String ServiceInfo()? ?? ???{? ?? ?? ?? ?return "我是ServceClassB";? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace SetterInjection{? ? internal class ClientClass? ? {? ?? ???private IServiceClass _serviceImpl;? ?? ?? ???public void Set_ServiceImpl(IServiceClass serviceImpl)? ?? ???{? ?? ?? ?? ?this._serviceImpl = serviceImpl;? ?? ???}? ?? ?? ???public void ShowInfo()? ?? ???{? ?? ?? ?? ?Console.WriteLine(_serviceImpl.ServiceInfo());? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace SetterInjection{? ? class Program? ? {? ?? ???static void Main(string[] args)? ?? ???{? ?? ?? ?? ?IServiceClass serviceA = new ServiceClassA();? ?? ?? ?? ?IServiceClass serviceB = new ServiceClassB();? ?? ?? ?? ?ClientClass client = new ClientClass();? ?? ?? ?? ?? ?client.Set_ServiceImpl(serviceA);? ?? ?? ?? ?client.ShowInfo();? ?? ?? ?? ?client.Set_ServiceImpl(serviceB);? ?? ?? ?? ?client.ShowInfo();? ?? ???}? ? }} 復(fù)制代碼
運行結(jié)果如下：
?
圖3.2 Setter注入運行結(jié)果
3.1.2 構(gòu)造注入
另外一種依賴注入方式，是通過客戶類的構(gòu)造函數(shù)，向客戶類注入服務(wù)類實例。
構(gòu)造注入（Constructor Injection）是指在客戶類中，設(shè)置一個服務(wù)類接口類型的數(shù)據(jù)成員，并以構(gòu)造函數(shù)為注入點，這個構(gòu)造函數(shù)接受一個具體的服務(wù)類實例為參數(shù)，并將它賦給服務(wù)類接口類型的數(shù)據(jù)成員。
?
圖3.3 構(gòu)造注入示意
圖3.3是構(gòu)造注入的示意圖，可以看出，與Setter注入很類似，只是注入點由Setter方法變成了構(gòu)造方法。這里要注意，由于構(gòu)造注入只能在實例化客戶類時注入一次，所以一點注入，程序運行期間是沒法改變一個客戶類對象內(nèi)的服務(wù)類實例的。
由于構(gòu)造注入和Setter注入的IServiceClass，ServiceClassA和ServiceClassB是一樣的，所以這里給出另外ClientClass類的示例代碼。
?
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace ConstructorInjection{? ? internal class ClientClass? ? {? ?? ???private IServiceClass _serviceImpl;? ?? ?? ???public ClientClass(IServiceClass serviceImpl)? ?? ???{? ?? ?? ?? ?this._serviceImpl = serviceImpl;? ?? ???}? ?? ?? ???public void ShowInfo()? ?? ???{? ?? ?? ?? ?Console.WriteLine(_serviceImpl.ServiceInfo());? ?? ???}? ? }} 復(fù)制代碼
可以看到，唯一的變化就是構(gòu)造函數(shù)取代了Set_ServiceImpl方法，成為了注入點。
3.1.3 依賴獲取
上面提到的注入方式，都是客戶類被動接受所依賴的服務(wù)類，這也符合“注入”這個詞。不過還有一種方法，可以和依賴注入達到相同的目的，就是依賴獲取。
依賴獲取（Dependency Locate）是指在系統(tǒng)中提供一個獲取點，客戶類仍然依賴服務(wù)類的接口。當客戶類需要服務(wù)類時，從獲取點主動取得指定的服務(wù)類，具體的服務(wù)類類型由獲取點的配置決定。
可以看到，這種方法變被動為主動，使得客戶類在需要時主動獲取服務(wù)類，而將多態(tài)性的實現(xiàn)封裝到獲取點里面。獲取點可以有很多種實現(xiàn)，也許最容易想到的就是建立一個Simple Factory作為獲取點，客戶類傳入一個指定字符串，以獲取相應(yīng)服務(wù)類實例。如果所依賴的服務(wù)類是一系列類，那么依賴獲取一般利用Abstract Factory模式構(gòu)建獲取點，然后，將服務(wù)類多態(tài)性轉(zhuǎn)移到工廠的多態(tài)性上，而工廠的類型依賴一個外部配置，如XML文件。
不過，不論使用Simple Factory還是Abstract Factory，都避免不了判斷服務(wù)類類型或工廠類型，這樣系統(tǒng)中總要有一個地方存在不符合OCP的if…else或switch…case結(jié)構(gòu)，這種缺陷是Simple Factory和Abstract Factory以及依賴獲取本身無法消除的，而在某些支持反射的語言中（如C#），通過將反射機制的引入徹底解決了這個問題（后面討論）。
下面給一個具體的例子，現(xiàn)在我們假設(shè)有個程序，既可以使用Windows風(fēng)格外觀，又可以使用Mac風(fēng)格外觀，而內(nèi)部業(yè)務(wù)是一樣的。
?
圖3.4 依賴獲取示意
上圖乍看有點復(fù)雜，不過如果讀者熟悉Abstract Factory模式，應(yīng)該能很容易看懂，這就是Abstract Factory在實際中的一個應(yīng)用。這里的Factory Container作為獲取點，是一個靜態(tài)類，它的“Type構(gòu)造函數(shù)”依據(jù)外部的XML配置文件，決定實例化哪個工廠。下面還是來看示例代碼。由于不同組件的代碼是相似的，這里只給出Button組件的示例代碼，完整代碼請參考文末附上的完整源程序。
?
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace DependencyLocate{? ? internal interface IButton? ? {? ?? ???String ShowInfo();? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace DependencyLocate{? ? internal sealed class WindowsButton : IButton? ? {? ?? ???public String Description { get; private set; }? ?? ?? ???public WindowsButton()? ?? ???{? ?? ?? ?? ?this.Description = "Windows風(fēng)格按鈕";? ?? ???}? ?? ?? ???public String ShowInfo()? ?? ???{? ?? ?? ?? ?return this.Description;? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace DependencyLocate{? ? internal sealed class MacButton : IButton? ? {? ?? ???public String Description { get; private set; }? ?? ?? ???public MacButton()? ?? ???{? ?? ?? ?? ?this.Description = " Mac風(fēng)格按鈕";? ?? ???}? ?? ?? ???public String ShowInfo()? ?? ???{? ?? ?? ?? ?return this.Description;? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace DependencyLocate{? ? internal interface IFactory? ? {? ?? ???IWindow MakeWindow();? ?? ?? ???IButton MakeButton();? ?? ?? ???ITextBox MakeTextBox();? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace DependencyLocate{? ? internal sealed class WindowsFactory : IFactory? ? {? ?? ???public IWindow MakeWindow()? ?? ???{? ?? ?? ?? ?return new WindowsWindow();? ?? ???}? ?? ?? ???public IButton MakeButton()? ?? ???{? ?? ?? ?? ?return new WindowsButton();? ?? ???}? ?? ?? ???public ITextBox MakeTextBox()? ?? ???{? ?? ?? ?? ?return new WindowsTextBox();? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace DependencyLocate{? ? internal sealed class MacFactory : IFactory? ? {? ?? ???public IWindow MakeWindow()? ?? ???{? ?? ?? ?? ?return new MacWindow();? ?? ???}? ?? ?? ???public IButton MakeButton()? ?? ???{? ?? ?? ?? ?return new MacButton();? ?? ???}? ?? ?? ???public ITextBox MakeTextBox()? ?? ???{? ?? ?? ?? ?return new MacTextBox();? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;using System.Xml;? ?namespace DependencyLocate{? ? internal static class FactoryContainer? ? {? ?? ???public static IFactory factory { get; private set; }? ?? ?? ???static FactoryContainer()? ?? ???{? ?? ?? ?? ?XmlDocument xmlDoc = new XmlDocument();? ?? ?? ?? ?xmlDoc.Load("http://www.cnblogs.com/Config.xml");? ?? ?? ?? ?XmlNode xmlNode = xmlDoc.ChildNodes[1].ChildNodes[0].ChildNodes[0];? ?? ?? ?? ?? ?if ("Windows" == xmlNode.Value)? ?? ?? ?? ?{? ?? ?? ?? ?? ? factory = new WindowsFactory();? ?? ?? ?? ?}? ?? ?? ?? ?else if ("Mac" == xmlNode.Value)? ?? ?? ?? ?{? ?? ?? ?? ?? ? factory = new MacFactory();? ?? ?? ?? ?}? ?? ?? ?? ?else? ?? ?? ?? ?{? ?? ?? ?? ?? ? throw new Exception("Factory Init Error");? ?? ?? ?? ?}? ?? ???}? ? }} 復(fù)制代碼
using System;using System.Collections.Generic;using System.Linq;using System.Text;? ?namespace DependencyLocate{? ? class Program? ? {? ?? ???static void Main(string[] args)? ?? ???{? ?? ?? ?? ?IFactory factory = FactoryContainer.factory;? ?? ?? ?? ?IWindow window = factory.MakeWindow();? ?? ?? ?? ?Console.WriteLine("創(chuàng)建 " + window.ShowInfo());? ?? ?? ?? ?IButton button = factory.MakeButton();? ?? ?? ?? ?Console.WriteLine("創(chuàng)建 " + button.ShowInfo());? ?? ?? ?? ?ITextBox textBox = factory.MakeTextBox();? ?? ?? ?? ?Console.WriteLine("創(chuàng)建 " + textBox.ShowInfo());? ?? ?? ?? ?? ?Console.ReadLine();? ?? ???}? ? }} 復(fù)制代碼
這里我們用XML作為配置文件。配置文件Config.xml如下：
?
<?xml version="1.0" encoding="utf-8" ?><config>? ? <factory>Mac</factory></config> 復(fù)制代碼
可以看到，這里我們將配置設(shè)置為Mac風(fēng)格，編譯運行上述代碼，運行結(jié)果如下：
?
圖3.5 配置Mac風(fēng)格后的運行結(jié)果
現(xiàn)在，我們不動程序，僅僅將配置文件中的“Mac”改為Windows，運行后結(jié)果如下：
?
圖3.6 配置為Windows風(fēng)格后的運行結(jié)果
從運行結(jié)果看出，我們僅僅通過修改配置文件，就改變了整個程序的行為（我們甚至沒有重新編譯程序），這就是多態(tài)性的威力，也是依賴注入效果。
3.2 反射與依賴注入
回想上面Dependency Locate的例子，我們雖然使用了多態(tài)性和Abstract Factory，但對OCP貫徹的不夠徹底。在理解這點前，朋友們一定要注意潛在擴展在哪里，潛在會出現(xiàn)擴展的地方是“新的組件系列”而不是“組件種類”，也就是說，這里我們假設(shè)組件就三種，不會增加新的組件，但可能出現(xiàn)新的外觀系列，如需要加一套Ubuntu風(fēng)格的組件，我們可以新增UbuntuWindow、UbuntuButton、UbuntuTextBox和UbuntuFactory，并分別實現(xiàn)相應(yīng)接口，這是符合OCP的，因為這是擴展。但我們除了修改配置文件，還要無可避免的修改FactoryContainer，需要加一個分支條件，這個地方破壞了OCP。依賴注入本身是沒有能力解決這個問題的，但如果語言支持反射機制（Reflection），則這個問題就迎刃而解。
我們想想，現(xiàn)在的難點是出在這里：對象最終還是要通過“new”來實例化，而“new”只能實例化當前已有的類，如果未來有新類添加進來，必須修改代碼。如果，我們能有一種方法，不是通過“new”，而是通過類的名字來實例化對象，那么我們只要將類的名字作為配置項，就可以實現(xiàn)在不修改代碼的情況下，加載未來才出現(xiàn)的類。所以，反射給了語言“預(yù)見未來”的能力，使得多態(tài)性和依賴注入的威力大增。
下面是引入反射機制后，對上面例子的改進：
?
圖3.7 引入反射機制的Dependency Locate
可以看出，引入反射機制后，結(jié)構(gòu)簡單了很多，一個反射工廠代替了以前的一堆工廠，Factory Container也不需要了。而且以后有新組件系列加入時，反射工廠是不用改變的，只需改變配置文件就可以完成。下面給出反射工廠和配置文件的代碼。
?
using System;using System.Collections.Generic;using System.Linq;using System.Text;using System.Reflection;using System.Xml;? ?namespace DependencyLocate{? ? internal static class ReflectionFactory? ? {? ?? ???private static String _windowType;? ?? ???private static String _buttonType;? ?? ???private static String _textBoxType;? ?? ?? ???static ReflectionFactory()? ?? ???{? ?? ?? ?? ?XmlDocument xmlDoc = new XmlDocument();? ?? ?? ?? ?xmlDoc.Load("http://www.cnblogs.com/Config.xml");? ?? ?? ?? ?XmlNode xmlNode = xmlDoc.ChildNodes[1].ChildNodes[0];? ?? ?? ?? ?? ?_windowType = xmlNode.ChildNodes[0].Value;? ?? ?? ?? ?_buttonType = xmlNode.ChildNodes[1].Value;? ?? ?? ?? ?_textBoxType = xmlNode.ChildNodes[2].Value;? ?? ???}? ?? ?? ???public static IWindow MakeWindow()? ?? ???{? ?? ?? ?? ?return Assembly.Load("DependencyLocate").CreateInstance("DependencyLocate." + _windowType) as IWindow;? ?? ???}? ?? ?? ???public static IButton MakeButton()? ?? ???{? ?? ?? ?? ?return Assembly.Load("DependencyLocate").CreateInstance("DependencyLocate." + _buttonType) as IButton;? ?? ???}? ?? ?? ???public static ITextBox MakeTextBox()? ?? ???{? ?? ?? ?? ?return Assembly.Load("DependencyLocate").CreateInstance("DependencyLocate." + _textBoxType) as ITextBox;? ?? ???}? ? }} 復(fù)制代碼
配置文件如下：
?
<?xml version="1.0" encoding="utf-8" ?><config>? ? <window>MacWindow</window>? ? <button>MacButton</button>? ? <textBox>MacTextBox</textBox></config> 復(fù)制代碼
反射不僅可以與Dependency Locate結(jié)合，也可以與Setter Injection與Construtor Injection結(jié)合。反射機制的引入，降低了依賴注入結(jié)構(gòu)的復(fù)雜度，使得依賴注入徹底符合OCP，并為通用依賴注入框架（如Spring.NET中的IoC部分、Unity等）的設(shè)計提供了可能性。
3.3 多態(tài)的活性與依賴注入
3.3.1 多態(tài)性的活性
這一節(jié)我們討論多態(tài)的活性及其與依賴注入類型選擇間密切的關(guān)系。
首先說明，“多態(tài)的活性”這個術(shù)語是我個人定義的，因為我沒有找到既有的概念名詞可以表達我的意思，所以就自己造了一個詞。這里，某多態(tài)的活性是指被此多態(tài)隔離的變化所發(fā)生變化的頻繁程度，頻繁程度越高，則活性越強，反之亦然。
上文說過，多態(tài)性可以隔離變化，但是，不同的變化，發(fā)生的頻率是不一樣的，這就使得多態(tài)的活性有所差別，這種差別影響了依賴注入的類型選擇。
舉例來說，本文最開始提到的武器多態(tài)性，其活性非常高，因為在那個程序中，Role在一次運行中可能更換多次武器。而現(xiàn)在我們假設(shè)Role也實現(xiàn)了多態(tài)性，這是很可能的，因為在游戲中，不同類型的角色（如暗夜精
靈、牛頭人、矮人等）很多屬性和業(yè)務(wù)是想通的，所以很可能通過一個IRole或AbstractRole抽象類實現(xiàn)多態(tài)性，不過，Role在實例化后（一般在用戶登錄成功后），是不會變化的，很少有游戲允許同一個玩家在運行中變換Role類型，所以Role應(yīng)該是一但實例化，就不會變化，但如果再實例化一個（如另一個玩家登錄），則可能就變化了。最后，還有一種多態(tài)性是活性非常低的，如我們熟悉的數(shù)據(jù)訪問層多態(tài)性，即使我們實現(xiàn)了SQL Server、Oracle和Access等多種數(shù)據(jù)庫的訪問層，并實現(xiàn)了依賴注入，但幾乎遇不到程序運行著就改數(shù)據(jù)庫或短期內(nèi)數(shù)據(jù)庫頻繁變動的情況。
以上不同的多態(tài)性，不但特征不同，其目的一般也不同，總結(jié)如下：
高活多態(tài)性——指在客戶類實例運行期間，服務(wù)類可能會改變的多態(tài)性。
中活多態(tài)性——指在客戶類實例化后，服務(wù)類不會改變，但同一時間內(nèi)存在的不同實例可能擁有不同類型的服務(wù)類。
低活多態(tài)性——指在客戶類實例化后，服務(wù)類不會改變，且同一時間內(nèi)所有客戶類都擁有相同類型的服務(wù)類。
以上三種多態(tài)性，比較好的例子就是上文提到的武器多態(tài)性（高活）、角色多態(tài)性（中活）和數(shù)據(jù)訪問層多態(tài)性（低活）。另外，我們說一種多態(tài)性是空間穩(wěn)定的，如果同一客戶類在同一時間內(nèi)的所有實例都依賴相同類型的服務(wù)類，反之則叫做空間不穩(wěn)定多態(tài)性。我們說一種多態(tài)性是時間穩(wěn)定的，如果一個客戶類在實例化后，所以來的服務(wù)類不能再次更改，反之則叫做時間不穩(wěn)定多態(tài)性。顯然，高活多態(tài)性時間和空間均不穩(wěn)定；中活多態(tài)性是時間穩(wěn)定的，但空間不穩(wěn)定；低活多態(tài)性時間空間均穩(wěn)定。
3.3.2 不同活性多態(tài)的依賴注入選擇
一般來說，高活多態(tài)性適合使用Setter注入。因為Setter注入最靈活，也是唯一允許在同一客戶類實例運行期間更改服務(wù)類的注入方式。并且這種注入一般由上下文環(huán)境通過Setter的參數(shù)指定服務(wù)類類型，方便靈活，適合頻繁變化的高活多態(tài)性。
對于中活多態(tài)性，則適合使用Constructor注入。因為Constructor注入也是由上下文環(huán)境通過Construtor的參數(shù)指定服務(wù)類類型，但一點客戶類實例化后，就不能進行再次注入，保證了其時間穩(wěn)定性。
而對于低活多態(tài)性，則適合使用Dependency Locate并配合文件配置進行依賴注入，或Setter、Constructor配合配置文件注入，因為依賴源來自文件，如果要更改服務(wù)類，則需要更改配置文件，一則確保了低活多態(tài)性的時間和空間穩(wěn)定性，二是更改配置文件的方式方便于大規(guī)模服務(wù)類替換。（因為低活多態(tài)性一旦改變行為，往往規(guī)模很大，如替換整個數(shù)據(jù)訪問層，如果使用Setter和Construtor傳參，程序中需要改變的地方不計其數(shù)）
本質(zhì)上，這種選擇是因為不同的依賴注入類型有著不同的穩(wěn)定性，大家可以細細體會“活性”、“穩(wěn)定性”和“依賴注入類型”之間密切的關(guān)系。
4 IoC Container
4.1 IoC Container出現(xiàn)的必然性
上面討論了諸多依賴注入的話題。說道依賴注入，就不能不說IoC Container（IoC容器），那么到底什么是IoC容器？我們還是先來看看它的出現(xiàn)背景。
我們知道，軟件開發(fā)領(lǐng)域有句著名的論斷：不要重復(fù)發(fā)明輪子！因為軟件開發(fā)講求復(fù)用，所以，對于應(yīng)用頻繁的需求，總是有人設(shè)計各種通用框架和類庫以減輕人們的開發(fā)負擔。例如，數(shù)據(jù)持久化是非常頻繁的需求，于是各種ORM框架應(yīng)運而生；再如，對MVC的需求催生了Struts等一批用來實現(xiàn)MVC的框架。
隨著面向?qū)ο蠓治雠c設(shè)計的發(fā)展和成熟，OOA&D被越來越廣泛應(yīng)用于各種項目中，然而，我們知道，用OO就不可能不用多態(tài)性，用多態(tài)性就不可能不用依賴注入，所以，依賴注入變成了非常頻繁的需求，而如果全部手工完成，不但負擔太重，而且還容易出錯。再加上反射機制的發(fā)明，于是，自然有人開始設(shè)計開發(fā)各種用于依賴注入的專用框架。這些專門用于實現(xiàn)依賴注入功能的組件或框架，就是IoC Container。
從這點看，IoC Container的出現(xiàn)有其歷史必然性。目前，最著名的IoC也許就是Java平臺上的Spring框架的IoC組件，而.NET平臺上也有Spring.NET和Unity等。
4.2 IoC Container的分類
前面曾經(jīng)討論了三種依賴注入方式，但是，想通過方式對IoC Container進行分類很困難，因為現(xiàn)在IoC Container都設(shè)計很完善，幾乎支持所有依賴注入方式。不過，根據(jù)不同框架的特性和慣用法，還是可以講IoC Container分為兩個大類。
4.2.1 重量級IoC Container
所謂重量級IoC Container，是指一般用外部配置文件（一般是XML）作為依賴源，并托管整個系統(tǒng)各個類的實例化的IoC Container。這種IoC Container，一般是承接了整個系統(tǒng)幾乎所有多態(tài)性的依賴注入工作，并承接了所有服務(wù)類的實例化工作，而且這些實例化依賴于一個外部配置文件，這種IoC Container，很像通過一個文件，定義整個系統(tǒng)多態(tài)結(jié)構(gòu)，視野宏大，想要很好駕馭這種IoC Container，需要一定的架構(gòu)設(shè)計能力和豐富的實踐經(jīng)驗。
Spring和Spring.NET是重量級IoC Container的例子。一般來說，這種IoC Container穩(wěn)定性有余而活性不足，適合進行低活多態(tài)性的依賴注入。
4.2.2 輕量級IoC Container
還有一種IoC Container，一般不依賴外部配置文件，而主要使用傳參的Setter或Construtor注入，這種IoC Container叫做輕量級IoC Container。這種框架很靈活，使用方便，但往往不穩(wěn)定，而且依賴點都是程序中的字符串參數(shù)，所以，不適合需要大規(guī)模替換和相對穩(wěn)定的低活多態(tài)性，而對于高活多態(tài)性，有很好的效果。
Unity是一個典型的輕量級IoC Container。
4.3 .NET平臺上典型IoC Container推介
4.3.1 Spring.NET
?
Spring.NET是Java平臺上Spring對.NET平臺的移植，使用方法和Spring很像，并且功能強大，是.NET平臺上大中型開發(fā)IoC Container的首選之一。除了DI外，Spring.NET也包括AOP等諸多功能。
4.3.2 Unity
?
對于小型項目和講求敏捷的團隊，Spring.NET可能有點太重量級，那么可以選擇輕量級的Unity。Unity是微軟patterns & practices團隊推出的輕量級框架，非常好用，目前最新版本是1.2。
總結(jié)
以上是生活随笔為你收集整理的依赖注入 这样的坑游戏编程要谨慎的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。
