Discretion refactoring series [13] & mdash; remove intermediate classes, discretion refactoring

Discretion refactoring series [13] -- remove intermediate classes and discretion refactoring

Sometimes we may write some "ghost" classes in our applications. "ghost" classes are also called intermediate classes. These intermediate classes may not do anything, but simply call other components. These intermediate classes do not actually work, they increase the layer of the application and increase the complexity of the application. At this time, we should delete such intermediate classes, or even delete the "middle layer" of the intermediate classes-this is the refactoring policy "remove intermediate classes" described in this article ".

Remove intermediate class diagram

This refactoring policy is easy to understand. The following figure shows the refactoring process.

Exceptions

Generally, invalid intermediate classes may be caused by misuse of design patterns.

If the design pattern is used properly, This refactoring strategy is not applicable, such as the scenario of "Facade Pattern", "adapter pattern", and "proxy pattern.

Below I will briefly describe the unsuitable scenarios in the "Facade mode.

Facade Mode

The facade mode provides a unified interface to access multiple different interfaces of multiple subsystems. It provides a unified high-level interface for a group of interfaces in the subsystem. This makes subsystems easier to use.

By distinguishing the use cases of "Facade mode", you can determine whether to use "Remove intermediate class ":

 
1. Customers only need to use a subset of a complex system, or use the facade mode when they need to interact with the system in a special way.
 
2. Use the facade mode to track the usage of the original system. Because all access to the system passes through FACADE, it is easy to monitor the use of the system.
 
3. To encapsulate and hide the original system.
 
4. The cost of writing a new category is less than that required by everyone to use and maintain the original system.

Before reconstruction

This Code defines three classes. Consumer depends on AccountManager and AccountManager depends on AccountDataProvider.

Hide code

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    }}

The AccountManager class, as an intermediate class, does not play any practical role. It just applies the work done by AccountDataProvider Based on Huludao.

After Reconstruction

After the intermediate class is removed, the Consumer class directly depends on the AccountDataProvider class.

Hide code

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    }}

[Note] keepfool