小酌重构系列[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