iT邦幫忙

DAY 8
7

如何提升系統設計品質 - 技術與工具以.NET為例系列 第 8

[如何提升系統品質-Day8]重構-抽象來看程式是否符合DRY原則

之前有提到,應該要抽象地去思考與設計程式。面對既存在的程式碼也是如此,如果看到的只是『一行一行』的程式碼,那就只是『見山是山』的程度。

許多好的軟體公司,都有code review的機制,code review基本上的方式,就是設計者應該要能『解釋』自己的程式碼是在做什麼。這個解釋,應該是用人話解釋,而不是解釋一行一行的程式碼語法。這個『用人話解釋』的過程,就是在抽象地解釋程式碼。這是很重要的經驗跟練習,當用人話說不清楚時,通常代表:
1.programmer不知道自己在寫什麼,也很有可能是copy/paste,或是亂抄範例
2.程式寫的不好解釋,缺少可讀性
3.程式太冗長,抽象等級參差不齊

這篇文章,我們會舉個簡單的例子,用抽象地方式來review我們的code,進而進行重構。或許不是很貼近現實,但我想抓住那個感覺就夠了。

[如何提升系統品質]系列文章連結
需求說明
我們手上有兩段code,分別是兩個Dao各自的方法:
1.FirstBankDao.UpdateOrInsert()

public class FirstBankDao
{
    /// <summary>
    /// 先檢查是否存在這筆資料,若不存在則呼叫新增,若存在則呼叫修改。
    /// </summary>
    /// <param name="id"></param>
    /// <param name="name"></param>
    public void UpdateOrInsert(Transaction data)
    {
        if (this.SelectCount(data) == 0)
        {
            this.Insert(data);
        }
        else
        {
            this.Update(data);
        }
    }
}
  1. ChinaTrustDao.Modify()

    public class ChinaTrustDao
    {
    public IChinaTrustBranchDao ChinaTrustBranchDao { get; set; }

    /// <summary>
    /// 檢查資料是否存在,如果不存在,則呼叫ChinaTrustBranchDao的新增,若存在,則呼叫修改。
    /// </summary>
    /// <param name="id"></param>
    public void Modify(Transaction data)
    {
        string getCountSql = @"your select count sqlstament";
        int count = this.ExecuteSql(getCountSql);
    
        if (count == 0)
        {
            //ChinaTrustBranchDao可能是一個WebService
            this.ChinaTrustBranchDao.Insert(data);
        }
        else
        {
            string updateSql = @"your update sqlstament";
            this.Update(updateSql);
        }
    
    }    
    

    }

這兩個class的方法內容,有一樣嗎?如果一行一行來看,幾乎完全不一樣。但是,從註解來看呢?這邊的註解是描述方法內容要做哪些事情,也就是抽象地說明方法的意義與作法。我們將註解裡面的重點抓出來看,有幾個關鍵字:
1.資料是否存在
2.不存在,就新增相關資料
3.存在,就修改相關資料

對這兩個方法的意義來說,上面這三個關鍵字是同樣的,而且判斷邏輯也一樣,他們是同一件事,但內容全然不同。那現在這樣的作法有不妥之處嗎?我認為沒有不妥的前提是:
1.這樣的動作,就只有這兩個class的這兩個方法用到
2.這部分邏輯以後不可能會有需求異動
3.以後需求異動,這兩者不會同時異動,也就是意義上是拆開的。

不過,PM對我們說:「未來可能還會新增其他的Dao,也是用相同的方式處理資料。而且我希望這樣的邏輯,以後修改的話,所有相關的程式邏輯都要一起變更。例如以後改成先刪除再新增,而不是先檢查再決定要新增或修改。」。面對PM這樣的要求,我們該如何設計呢?我們用的方法是Design pattern裡面的Template Method。(為什麼叫做Template?因為骨頭都是一樣的,但細節內容可以不一樣)

設計步驟
步驟一:
替我們的Template命個名字,這樣的動作,通常畫面上就叫做『存檔』,那我們就叫Save吧。這個Save的方法,這兩個Dao都要能夠重用,而且未來要新增其他同樣操作的Dao要很便利。因此,我們定義一個父類別來供其他類別繼承。

步驟二:
Template的骨頭建好了,但是要做的事情,子類別都不一樣,應該將內容交給子類別來決定。所以通常只有兩種作法,要嘛宣告成abstract讓子類別繼承後override,要嘛拉到interface上,讓實作的class自行決定內容。這邊,我們只能用abstract。為什麼?不是interface比較抽象嗎?如果什麼都可以用interface來取代abstract的話,那abstract這個關鍵字可能早就消失了。

因為我們要有固定的template,我們想把邏輯定義好,內容才交給子類別決定。interface是不能有方法內容的,所以interface無法幫我們定義出一個固定的邏輯來重複使用。(一個系統重用程度看Abstract,抽象程度看Interface)

這邊要補充說明一下,可以限制Save()不可以被子類別覆寫,來限制所有子類別都需遵守abstract class所定義的邏輯。而Template method中,用到的abstract method,可自行根據需求來定義對應的visibility,不過不能宣告成private,因為它需要被子類別繼承覆寫。

步驟三:
接著讓我們的兩個Dao來繼承AbstractDao,然後將原本Modify的內容移至對應的位置。

搬完code的樣子:

步驟四:
另一個Dao也如法炮製。

步驟五:
將兩個方法的名字透過重構,重新命名成Save,讓所有原本有用到此方法,都改成呼叫Save(),然後再把子類別的Save方法刪掉,讓呼叫子類別的Save方法時,會自動呼叫到AbstractDao裡面的Save()。(這邊有個前提是相容性的問題,這裡重新命名,已經在使用這顆dll的系統並不會跟著被重新命名。)

如此一來,以後要用這個邏輯就只需要呼叫Save就可以了。我們Save的方法,在需要增加新的Dao時,只需要繼承AbstractDao即可。

結論
這邊我們使用了Template Method來重構我們的『邏輯』,以避免重複邏輯的程式碼被分散,未來需求異動得修改很多份,也避免了新的類別需要用到同樣的邏輯得重複開發。

有興趣的人也可以參考『重構-改善既有程式的設計』中的11.10,Form Template Method,寫得比我文章詳細很多。


上一篇
[如何提升系統品質-Day7]測試-單元測試, Just Do It!!
下一篇
[如何提升系統品質-Day9]重構-簡化判斷式
系列文
如何提升系統設計品質 - 技術與工具以.NET為例30

1 則留言

0

我要留言

立即登入留言