Should I use abstract or virtual methods?

Question

If we assume that it is not desirable for the base class to be a pure interface class, and using the 2 examples from below, which is a better approach, using the abstract or virtual method class definition?

• The advantage of "abstract" version is that it is probably looks cleaner and forces the derived class to give a hopefully meaningful implementation.

• The advantage of the "virtual" version is that it can be easily pulled in by other modules and used for testing without adding a bunch of underlying framework like the abstract version requires.

Abstract Version:

public abstract class AbstractVersion
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

Virtual Version:

public class VirtualVersion
{
    public virtual ReturnType Method1()
    {
        return ReturnType.NotImplemented;
    }

    public virtual ReturnType Method2()
    {
        return ReturnType.NotImplemented;
    }
             .
             .
    public virtual ReturnType MethodN()
    {
        return ReturnType.NotImplemented;
    }

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

Answer 1

My vote, if I were consuming your stuff, would be for the abstract methods. That goes along with "fail early." It may be a pain at declaration time to add all methods (though any decent refactoring tool will do this quickly), but at least I know what the problem is immediately and fix it. I'd rather that than be debugging 6 months and 12 people's worth of changes later to see why we're suddenly getting a not implemented exception.

Answer 2

The virtual version is both bug prone and semantically incorrect.

Abstract is saying "this method isn't implemented here. you must implement it to make this class work"

Virtual is saying "I have a default implementation but you can change me if you need"

If your ultimate objective is testability then interfaces are normally the best option. (this class does x rather than this class is a x). You might need to break your classes into smaller components though for this to work nicely.

Answer 3

This depends on the usage of your class.

If the methods have some reasonable “empty” implementation, you have lots of methods and you often override just a few of them, then using virtual methods makes sense. For example ExpressionVisitor is implemented this way.

Otherwise, I think you should use abstract methods.

Ideally, you shouldn't have methods that are not implemented, but in some cases, that is the best approach. But if you decide to do that, such methods should throw NotImplementedException, not return some special value.

Answer 4

I would suggest that you reconsider having a separate interface defined which your base class implements, and then you follow the abstract approach.

Imaging code like this:

public interface IVersion
{
    ReturnType Method1();        
    ReturnType Method2();
             .
             .
    ReturnType MethodN();
}

public abstract class AbstractVersion : IVersion
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

Doing this solves these problems:

1. By having all code that uses objects derived from AbstractVersion can now be implemented to receive IVersion interface instead, This means that they can be more easily unit tested.

2. Release 2 of your product can then implement an interface IVersion2 to provide additional functionality without breaking your existing customers code.

eg.

public interface IVersion
{
    ReturnType Method1();        
    ReturnType Method2();
             .
             .
    ReturnType MethodN();
}

public interface IVersion2
{
    ReturnType Method2_1();
}

public abstract class AbstractVersion : IVersion, IVersion2
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();
    public abstract ReturnType Method2_1();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

It's also worth reading up about dependency inversion as well, to prevent this class from containing hard coded dependencies that prevent effective unit testing.

Answer 5

Dependency injection relies on interfaces. Heres a short example. Class Student has a function called CreateStudent that requires a parameter that implements interface "IReporting" (with a ReportAction method). After it creates a student it calls ReportAction on the concrete class parameter. If the system is set up to send an email after creating a student we send in a concrete class that sends an email in its ReportAction implementation, or we could send in another concrete class that sends output to a printer in its ReportAction implementation. Great for code re-use.