小酌重構系列[13]——移除中間類

咱們有時候在應用程序中可能編寫了一些「幽靈」類，「幽靈」類也叫中間類。這些中間類可能什麼事兒都沒作，而只是簡單地調用了其餘的組件。這些中間類沒有發揮實際的做用，它們增長了應用程序的層級（layer），而且增長了應用程序的複雜性。這時，咱們應將這樣的中間類刪除，甚至刪除中間類所處的「中間層」——這就是本文要講的重構策略「移除中間類」。

移除中間類

圖說

這個重構策略比較容易理解，下面這幅圖演示了它的重構過程。

例外

一般狀況下，無效的中間類多是由於濫用設計模式而形成的。

若是設計模式使用的恰當，這個重構策略就不適用了，好比用「門面模式」、「適配器模式」和「代理模式」的場景。

下面我以「門面模式」簡單說明一下不適用的場景。

門面模式

門面模式，是指提供一個統一的接口去訪問多個子系統的多個不一樣的接口，它爲子系統中的一組接口提供一個統一的高層接口。使得子系統更容易使用。

經過區分「門面模式」的使用場景，能夠判斷是否應該使用「移除中間類」：

一、客戶只須要使用某個複雜系統的子集，或者須要以一種特殊的方式與系統交互時，使用門面模式。

二、當須要跟蹤原系統的使用狀況時 ，使用門面模面模式。由於全部對系統的訪問都通過FACADE,因此能夠很容易地監視系統的使用 。

三、 但願封裝和隱藏原系統時。

四、編寫新類的成本小於全部人使用和維護原系統使用所需的成本時

示例

重構前

這段代碼定義了3個類，Consumer依賴於AccountManager，AccountManager依賴於AccountDataProvider。

隱藏代碼

public class Consumer
{
    public AccountManager AccountManager { get; set; }

    public Consumer(AccountManager accountManager)
    {
        AccountManager = accountManager;
    }

    public void Get(int id)
    {
        Account account = AccountManager.GetAccount(id);
    }
}

public class AccountManager
{
    public AccountDataProvider DataProvider { get; set; }

    public AccountManager(AccountDataProvider dataProvider)
    {
        DataProvider = dataProvider;
    }

    public Account GetAccount(int id)
    {
        return DataProvider.GetAccount(id);
    }
}

public class AccountDataProvider
{
    public Account GetAccount(int id)
    {
        // get account
    }
}

AccountManager類做爲中間類，沒有起到任何實際的做用，它只是依葫蘆畫瓢地套用了AccountDataProvider作的事情。

重構後

移除中間類後，Consumer類直接依賴於AccountDataProvider類。

隱藏代碼

public class Consumer
{
    public AccountDataProvider AccountDataProvider { get; set; }

    public Consumer(AccountDataProvider dataProvider)
    {
        AccountDataProvider = dataProvider;
    }

    public void Get(int id)
    {
        Account account = AccountDataProvider.GetAccount(id);
    }
}

public class AccountDataProvider
{
    public Account GetAccount(int id)
    {
        // get account
    }
}

小酌重構系列目錄彙總

關注keepfool