Refactoring to Abstract Base Class – Default Implementation Strategies

abstract classcrefactoring

I have a class which aggregates some temporal data from a database and provides a bunch of methods to query said data. It looks like this:

public class InfoProvider
{
    public IEnumerable<Contract> GetContracts() => GetContracts(DateTime.Today);
    public IEnumerable<Contract> GetContracts(DateTime at) => GetContracts(at, at);
    public IEnumerable<Contract> GetContracts(DateTime from, DateTime to) { /* query contracts */ }

    public IEnumerable<Job> GetJobs() => GetJobs(DateTime.Today);
    public IEnumerable<Job> GetJobs(DateTime at) => GetJobs(at, at);
    public IEnumerable<Job> GetJobs(DateTime from, DateTime to) { /* query jobs */ }

    /* more methods like above ... */
}

Now I need to extend my application to support different representations of the data in the database. Those representations are identical for the most part but have some subtle differences. For example GetContracts in representation 1 should return contracts of type A, B or C while in representation 2 it should return contracts only of type A or B. On the contrary, GetJobs would be the same in both representations.

I want to do this extension by refactoring InfoProvider into an abstract class and derive concrete classes, InfoProviderRepresentation1 and InfoProviderRepresentation2 for each representation. But I waver where to put the existing code. I see those two options:

Leave it in the original class

public abstract class InfoProvider
{
    public IEnumerable<Contract> GetContracts() => GetContracts(DateTime.Today);
    public IEnumerable<Contract> GetContracts(DateTime at) => GetContracts(at, at);
    public virtual IEnumerable<Contract> GetContracts(DateTime from, DateTime to) { /* query contracts */ }

    public IEnumerable<Job> GetJobs() => GetJobs(DateTime.Today);
    public IEnumerable<Job> GetJobs(DateTime at) => GetJobs(at, at);
    public virtual IEnumerable<Job> GetJobs(DateTime from, DateTime to) { /* query jobs */ }
}

public class InfoProviderRepresentation1 : InfoProvider
{
}

public class InfoProviderRepresentation2 : InfoProvider
{
    public override IEnumerable<Contract> GetContracts(DateTime from, DateTime to) { /* ... */ }
}

Move the code to an other abstract class and derive my concrete classes from there:

public abstract class InfoProvider
{
    public IEnumerable<Contract> GetContracts() => GetContracts(DateTime.Today);
    public IEnumerable<Contract> GetContracts(DateTime at) => GetContracts(at, at);
    public abstract IEnumerable<Contract> GetContracts(DateTime from, DateTime to);

    public IEnumerable<Job> GetJobs() => GetJobs(DateTime.Today);
    public IEnumerable<Job> GetJobs(DateTime at) => GetJobs(at, at);
    public abstract IEnumerable<Job> GetJobs(DateTime from, DateTime to);
}

public abstract class DefaultInfoProvider
{
    public virtual IEnumerable<Contract> GetContracts(DateTime from, DateTime to) { /* query contracts */ }
    public virtual IEnumerable<Job> GetJobs(DateTime from, DateTime to) { /* query jobs */ }
}

public class InfoProviderRepresentation1 : DefaultInfoProvider
{
}

public class InfoProviderRepresentation2 : DefaultInfoProvider
{
    public override IEnumerable<Contract> GetContracts(DateTime from, DateTime to) { /* ... */ }
}

I find option 2 a bit more readable. On the other hand it needs more boilerplate code than option 1. Does option 2 have any more advantages over option 1?

Best Answer

This is the kind of question that you can ask a dozen different people and get a dozen different answers. I say do the simplest thing that solves your problem: if all you need to do is override GetContracts, don't even bother creating an abstract class, just derive from your existing class and override it. If you find yourself doing this a whole bunch and things start getting messy, then you can look into other strategies such as interface segregation and composition.

Related Solutions

C# Design Patterns – Using Abstract Base Class with Interfaces as Behaviors

[1] Add virtual "getters" & "setters" to your properties, I had to hack another control library, because I need this feature:

abstract class Control
{
    // internal fields for properties
    protected int _Width;
    protected int _Height;
    protected int _BackColor;
    protected int _X;
    protected int _Y;
    protected bool Visible;

    protected int BorderWidth;
    protected int BorderColor;


    // getters & setters virtual !!!

    public virtual int getWidth(...) { ... }
    public virtual void setWidth(...) { ... }

    public virtual int getHeight(...) { ... }
    public virtual void setHeight(...) { ... }

    public virtual int getBackColor(...) { ... }
    public virtual void setBackColor(...) { ... }

    public virtual int getX(...) { ... }
    public virtual void setX(...) { ... }

    public virtual int getY(...) { ... }
    public virtual void setY(...) { ... }

    public virtual int getBorderWidth(...) { ... }
    public virtual void setBorderWidth(...) { ... }

    public virtual int getBorderColor(...) { ... }
    public virtual void setBorderColor(...) { ... }

    public virtual bool getVisible(...) { ... }
    public virtual void setVisible(...) { ... }

    // properties WITH virtual getters & setters

    public int Width { get getWidth(); set setWidth(value); }

    public int Height { get getHeight(); set setHeight(value); }

    public int BackColor { get getBackColor(); set setBackColor(value); }

    public int X { get getX(); set setX(value); }

    public int Y { get getY(); set setY(value); }

    public int BorderWidth { get getBorderWidth(); set setBorderWidth(value); }

    public int BorderColor { get getBorderColor(); set setBorderColor(value); }

    public bool Visible { get getVisible(); set setVisible(value); }

    // other methods

    public Rectangle ClipRectange { get; protected set; }   
    abstract public void Draw();
} // class Control

/* concrete */ class MyControl: Control
{
    public override bool getVisible(...) { ... }
    public override void setVisible(...) { ... }
} // class MyControl: Control

I know this suggestion is more "verbose" or complex, but, its very useful in real world.

[2] Add an "IsEnabled" property, do not confuse with "IsReadOnly":

abstract class Control
{
    // internal fields for properties
    protected bool _IsEnabled;

    public virtual bool getIsEnabled(...) { ... }
    public virtual void setIsEnabled(...) { ... }

    public bool IsEnabled{ get getIsEnabled(); set setIsEnabled(value); }
} // class Control

Means you may have to show your control, but don't show any information.

[3] Add a "IsReadOnly" property, do not confuse with "IsEnabled":

abstract class Control
{
    // internal fields for properties
    protected bool _IsReadOnly;

    public virtual bool getIsReadOnly(...) { ... }
    public virtual void setIsReadOnly(...) { ... }

    public bool IsReadOnly{ get getIsReadOnly(); set setIsReadOnly(value); }
} // class Control

That means the control can display information, but cannot be changed by the user.

C# Abstract Class – Should Public Methods Be Virtual?

However, as long as you trust that Liskov's Substitution Principle will be followed, then why would you not allow it to be overriden?

For example, because I want the skeleton implementation of an algorithm to be fixed, and only allow specific parts to be (re)defined by subclasses. This is widely known as the Template Method pattern (emphasis below by me):

The template method thus manages the larger picture of task semantics, and more refined implementation details of selection and sequence of methods. This larger picture calls abstract and non-abstract methods for the task at hand. The non-abstract methods are completely controlled by the template method but the abstract methods, implemented in subclasses, provide the pattern's expressive power and degree of freedom. Some or all of the abstract methods can be specialized in a subclass, allowing the writer of the subclass to provide particular behavior with minimal modifications to the larger semantics. The template method (which is non-abstract) remains unchanged in this pattern, ensuring that the subordinate non-abstract methods and abstract methods are called in the originally-intended sequence.

Update

Some concrete examples of projects I have been working on:

communicating with a legacy mainframe system via various "screens". Each screen has a bunch of fields, of fixed name, position and length, containing specific data bits. A request fills up certain fields with specific data. A response returns data in one or more other fields. Each transaction follows the same basic logic, but the details are different on every screen. We used Template Method in several different projects to implement the fixed skeleton of the screen handling logic, while allowing subclasses to define the screen-specific details.
exporting / importing configuration data in DB tables to/from Excel files. Again, the basic schema of processing an Excel file and inserting/updating DB records, or dumping the records to Excel is the same for each table, but the details of each table are different. So Template Method is a very obvious choice to eliminate code duplications and make the code easier to understand and maintain.
Generating PDF documents. Each document has the same structure, but their content is different each time, depending on lots of factors. Again, Template Method makes it easy to separate the fixed skeleton of the generation algorithm from the case-specific, changeable details. In fact. it even applies on multiple levels here, as the document consists of several sections, each of which consists of zero or more fields. Template Method is applied on 3 distinct levels here.

In the first two cases, the original legacy implementation used Strategy, resulting in lots of duplicated code, which of course over the years grew subtle differences here and there, contained lots of duplicated or slightly different bugs, and was very difficult to maintain. Refactoring to Template Method (and some other enhancements, like using Java annotations) reduced code size by about 40-70%.

These are only the most recent examples which come to my mind. I could cite more cases from almost every project I have been working on so far.

Best Answer

Related Solutions

C# Design Patterns – Using Abstract Base Class with Interfaces as Behaviors

C# Abstract Class – Should Public Methods Be Virtual?

Update

Related Topic