[30天快速上手TDD][Day 6]隔絕相依性的方式與特性

[30天快速上手TDD][Day 6]隔絕相依性的方式與特性

前言

在上一篇文章中,提到了如何透過 IoC 的設計,以及 Stub Object 的方式,來獨立測試目標物件。

這一篇文章,則要說明有哪些設計物件的方式,可以讓測試或需求異動時,更容易抽換。

並說明這些方式有哪些特性,供讀者朋友們在設計時,可以選擇適合自己情境的方式來使用。

 

需求說明

當呼叫目標物件的方法時,期望目標物件的內容可以不必關注相依於哪些實體物件,而只需要相依於某個介面,透過這樣的方式來達到設計的彈性與可獨立測試性。

那麼,有哪一些方式可以達到這樣的目的呢?

 

建構式(constructor)

描述:

上一篇文章範例所使用的方式,將物件的相依介面,拉到公開的建構式,供外部物件使用時,可自行組合目標物件的相依物件實體。

程式碼如下:

    public class Validation
    {
        private IAccountDao _accountDao;
        private IHash _hash;

        public Validation(IAccountDao dao, IHash hash)
        {
            this._accountDao = dao;
            this._hash = hash;
        }

        public bool CheckAuthentication(string id, string password)
        {
            var passwordByDao = this._accountDao.GetPassword(id);
            var hashResult = this._hash.GetHashResult(password);

            return passwordByDao == hashResult;
        }
    }

 

好處:

有許多 DI framework 支援 Autowiring。

Autowiring is an automatic detection of dependency injection points.

這邊的 dependency injection points 在這例子,指的就是建構式。以 Unity 為例,在 UnityContainer 取得目標物件時,會自動尋找目標物件參數最多的建構式。並針對每一個參數的型別,繼續在 UnityContainer 中尋找對應的實體物件,直到目標物件組合完畢,回傳一個完整的目標物件。

由建構式傳入相依介面的實體物件,是一個很通用的方式。因此在結合許多常見的 DI framework,不需要再額外處理。

 

顧慮點:

當物件越來越複雜時,建構式也會趨於複雜。倘若沒有 DI framework 的輔助,則使用物件上,面對許多 overload 的建構式,或是一個建構式參數有好幾個,會造成使用目標物件上的困難與疑惑。若沒有好好進行 refactoring,也可能因此而埋藏許多 bad smell。

另外,倘若是許多建構式,也可能造成要呼叫 A 方法時,應選用 A 對應的建構式,但在使用物件上,可能會用錯建構式而不自知,若方法中沒有正確的防呆,則可能出現錯誤。(請搭配單元測試的測試案例來輔助)

最後,與原本直接相依的程式碼相比較,目標物件的相依物件因此暴露出來,交由外部決定,而喪失了一點封裝的意味。而使用端也不一定知道,要取用此物件時,應該要注入哪些相依物件。(請使用 Repository Pattern 或 DI framework 來輔助)

 

公開屬性(public setter property)

描述:

其實公開屬性與公開建構式非常類似,透過 public 的 property(property 型別仍為 interface),讓外部在使用目標物件時,可先 setting 目標物件的相依物件,接著才呼叫其方法。

而公開屬性通常只會將 setter 公開給外部設定,getter 則設定為 private。原因很簡單,外部只需設定,而不需取用。就像公開建構式,在使用物件之前先傳入初始化物件必備的資訊,但目標物件可能將這些資訊,存放在 private 的 filed 或 property 中,而不需再提供給外部使用。

程式碼如下:

    public class Validation
    {
        public IAccountDao AccountDao { private get; set; }

        public IHash Hash { private get; set; }

        public bool CheckAuthentication(string id, string password)
        {
            if (this.AccountDao == null)
            {
                throw new ArgumentNullException();
            }

            if (this.Hash == null)
            {
                throw new ArgumentNullException();
            }

            var passwordByDao = this.AccountDao.GetPassword(id);
            var hashResult = this.Hash.GetHashResult(password);

            return passwordByDao == hashResult;
        }
    }

 

好處:

同樣的,public property 也是常見的 dependency injection points,所以也有許多 DI framework 支援。另外則是不需要對建構式進行改變,或增加新的建構式。對過去已經存在的 legacy code 的影響,會比建構式的方式小一點點(但幾乎沒有太大差異)。

 

顧慮點:

最常見的情況,就是使用目標物件時,相依介面應有其對應執行個體,但卻因為使用端沒有設定 public property,導致使用方法時出現 NullReferenceException,這種情況也怪不了使用端,因為使用端極有可能本就不瞭解這個方法中,有哪些相依物件。

解決方式與建構式的建議雷同,首先當然要有測試程式來說明(測試程式就是物件使用說明書),另外取得目標物件,仍可透過 Repository Pattern,讓使用端無須瞭解目標物件的相依關係。

並且在方法中使用相依介面前,應檢查其是否為 null,若為 null,則代表參數設定錯誤,進行 error handling,避免已經發生錯誤仍執行許多不應執行的程式碼。或是在 property 的 getter 時,檢查是否為 null 或當為 null 時,給予一預設值,以避免方法無法正常執行。(視實際需求而定)

另外,公開屬性的方式,也如同公開建構式一般,破壞了一點點物件封裝的用意。但這兩者,都是 IoC 設計會帶來的影響。

 

呼叫方法時傳入參數(function parameter)

描述:

既然前面兩種方式,都可能造成使用方法時,可能沒有設定好相依介面的執行個體,導致發生錯誤。或是使用目標物件時,不知道該呼叫哪一個建構式或初始化哪些屬性。那很簡單的方式,就是把方法相依介面的部分,拉到方法的參數上。方法中,需要使用到哪些介面,強迫由呼叫端必須給定參數。目標物件的方法內容則僅相依於參數上的介面。

程式碼如下:

        public bool CheckAuthentication(IAccountDao accountDao, IHash hash, string id, string password)
        {
            var passwordByDao = accountDao.GetPassword(id);
            var hashResult = hash.GetHashResult(password);

            return passwordByDao == hashResult;
        }

 

好處:

不必再擔心要先初始化哪些 property,或呼叫哪一個建構式。當要呼叫某一個方法,其相依的物件,就是得透過參數來給定。基本上也不太需要擔心使用上造成困擾或迷惑。

 

顧慮點:

最大的問題,在於方法簽章上的不穩定性。當需求異動,該方法需要額外相依於其他物件時,方法簽章可能會被迫改變。而方法簽章是物件導向設計上,最需要穩定的條件之一。以物件導向、介面導向設計來說,當多型物件方法簽章不一致時,向來是個大問題。

另外,方法的參數過多,在使用上也會造成困擾。而且會影響到 legacy code 的呼叫端,需要全面跟著異動,才能編譯成功。

而且透過參數的方式,DI framework 支援度較低。

但這不代表,就不能在方法參數中,傳入相依物件。在 .net framework 還是有許多這樣的設計,例如:List<T>.Sort 方法 (IComparer<T>)。這樣的設計方式,通常要確保該方法相依相當明確、穩固,避免上述問題。

by the way, 這個方式是可以與其他方式共存的,所以在設計物件時,可衡量搭配使用。

 

可覆寫的保護方法(protected virtual function)

描述:

前面的三種方式,基本上都對外暴露了原本可能不需要對外暴露的細節。倘若,現在的需求是眼前的程式要進行測試,但又不希望影響或修改使用端的程式,那麼該怎麼作呢?除了可以透過公開屬性設定,當為空時給予預設值的方式,來維持原本物件的內部程式邏輯以外,還有一個相當簡單的方式,甚至有些情況不需要透過介面設計,就可以進行測試。

先來看看原本直接相依物件,無法測試的程式,程式碼如下:

    public class Validation
    {
        public bool CheckAuthentication(string id, string password)
        {
            var accountDao = new AccountDao();
            var passwordByDao = accountDao.GetPassword(id);

            var hash = new Hash();
            var hashResult = hash.GetHashResult(password);

            return passwordByDao == hashResult;
        }
    }

接下來,我們只用簡單的物件導向概念:繼承、覆寫,就可以對 Validation 物件的 CheckAuthentication 方法進行測試。不相信嗎?繼續往下看下去。

首先,一定要記得,把 new 物件的動作抽離高層抽象的 context 中。(可以透過 extract method 的方式抽離)

程式碼如下:

    public class Validation
    {
        public bool CheckAuthentication(string id, string password)
        {
            var accountDao = GetAccountDao();
            var passwordByDao = accountDao.GetPassword(id);

            var hash = GetHash();
            var hashResult = hash.GetHashResult(password);

            return passwordByDao == hashResult;
        }

        private Hash GetHash()
        {
            var hash = new Hash();
            return hash;
        }

        private AccountDao GetAccountDao()
        {
            var accountDao = new AccountDao();
            return accountDao;
        }
    }

沒什麼改變,對吧?

接下來,將兩個 new 物件的方法,宣告為 protected virtual,代表子類別可以繼承與覆寫該方法。程式碼如下:

        protected virtual Hash GetHash()
        {
            var hash = new Hash();
            return hash;
        }

        protected virtual AccountDao GetAccountDao()
        {
            var accountDao = new AccountDao();
            return accountDao;
        }

另外,將要使用到 Hash 與 AccountDao 的方法,也要宣告為 virtual。程式碼如下:

    public class AccountDao
    {
        public virtual string GetPassword(string id)
        {
            throw new NotImplementedException();
        }
    }

    public class Hash
    {
        public virtual string GetHashResult(string password)
        {
            throw new NotImplementedException();
        }
    }

到這邊,都不影響外部使用目標物件的行為,我們只是在重構物件的內部方法罷了。事實上,我們可測試性的動作也準備完畢了。(當然,建議還是要相依於介面,實作介面要顧慮的點,比繼承類別要輕鬆的多)

接下來把目光切到測試程式,該如何對 CheckAuthentication 方法進行測試。

首先,將上一篇文章的 StubHash 改為繼承自 Hash,StubAccountDao 改為繼承自 AccountDao,並將原本 public 的方法,加上 override 關鍵字,覆寫其父類方法內容。程式碼如下:

    public class StubAccountDao : AccountDao
    {
        public override string GetPassword(string id)
        {
            return "91";
        }
    }

    public class StubHash : Hash
    {
        public override string GetHashResult(string password)
        {
            return "91";
        }
    }

不難,對吧。接下來,建立一個 MyValidation 的 class,繼承自 Validation。並覆寫 GetAccountDao() 與 GetHash(),使其回傳 Stub Object。程式碼如下:

    public class MyValidation : Validation
    {
        protected override AccountDao GetAccountDao()
        {
            return new StubAccountDao();
        }

        protected override Hash GetHash()
        {
            return new StubHash();
        }
    }

也不難,對吧。接下來,來設計單元測試,程式碼如下:

        [TestMethod()]
        public void CheckAuthenticationTest()
        {
            Validation target = new MyValidation();

            string id = "id隨便啦";
            string password = "密碼也沒關係";

            bool expected = true;

            bool actual;
            actual = target.CheckAuthentication(id, password);

            Assert.AreEqual(expected, actual);
        }

原本初始化的測試目標為 Validation 物件,現在則為 MyValidation 物件。裡面唯一不同的部分,只有覆寫的方法內容,其餘 MyValidation 就等同於 Validation。(Is-A的關係

偵錯測試一下,就可以確認,程式碼就跟之前使用 IoC 的方式執行沒有太大的差異。請見下圖:

Day6 virtual override testing

 

好處:

這個方式最大的好處,是完全不影響外部使用物件的方式。僅透過 protected 與 virtual 來對繼承鏈開放擴充的功能,並且透過這樣的方式,就使得原本直接相依而導致無法測試的問題,獲得解套。

 

顧慮點:

這是為了測試,且面對 legacy code 所使用的方式,而不是良好的物件導向設計的方式。IoC 的用意在於介面導向與擴充點的彈性,所以當可測試之後,倘若重構影響範圍不大,建議讀者朋友還是要將物件改相依於介面,透過 IoC 的方式來設計物件。

by the way, 同樣為了解決直接相依物件,甚至相依於 static 方法、.net framework 本身的物件(如 DateTime.Now)而導致無法測試的問題,還有另外一個方式,稱為 fake object。這在後面的文章,會再進行較為詳盡的介紹。

 

結論

以上幾種用來測試的方式,希望對各位讀者在不同情境下的設計,可以有所幫助。

而許多延伸的議題,在這系列文章並不會多談,但在實務應用面上,卻是相當重要的配套措施。例如一再提到的 DI framework, Repository Pattern,以及透過測試程式來說明物件的使用方式,請讀者在實務設計系統時,務必瞭解這些東西如何讓系統設計更加完整。

下一篇文章,將介紹怎麼樣可以避免每次手工刻這麼囉唆的 stub 物件,怎麼針對 static 或 .net framework 本身的物件進行隔離,怎麼針對物件與相依介面互動的情況進行測試。

 

對敏捷開發有興趣的朋友,可以參考我的粉絲專頁:91敏捷開發之路

對 TDD 課程有興趣的朋友,課程內容、大綱與學員心得,可以參考 skilltree 的公開課程:自動測試與 TDD 實務開發

若需要聯絡我,可以透過粉絲專頁私訊或是側欄的關於我。