Interfaces vs Base class

Question

I'm strugging to know when to use a base class with Polymorphism or an interface.

Providing my object exposes DoThis() then I can't see why it matters if it's an interface of a base class.

Please consider the following

public void MyMethod()
{
    var myObject = new MyObject();
    myObject.DoThis();
}

In regards to MyObject, I could have created it in 2 ways

Approach 1

public class MyObject : IMyInterface
{
    public void DoThis()
    {
        //logic
    } 
}

Approach 2

public class MyObject : MyBaseObject
{
    public override void DoThis()
    {
        //logic
    } 
}

From what I can see, both of these implementations achieve the same thing.

The issue could be my example is too simple/contrived but, is there a way to know when to use one approach over the other? In my example above, I would guess the answer is preference? I've not done any big projects before and so I'm guessing that one isn't as extendible but I don't know why I think that!

Answer 1

In C#, there are two (major) things that differ between interfaces and abstract classes:

1. You can implement more than one interface, but only one class.
2. To be able to do that, you can't do some things in an interface that you can do on the base class - most commonly, implement any sort of default/common implementations.

One new caveat to this is that in .net 3.5 and later, you can create extension methods for interfaces. This can provide common or default behavior for instance methods, but not other members.

Most people will say to make an interface until you need the capabilities of an abstract base type. I urge a different approach:

Certainly there will be times when the functional differences will force your hand, but the choice also guides users in the use of your types. Use interfaces when you are conceptually describing a trait, or some property to be implemented. Something that can conceivably be implemented alongside other interfaces without violating the Single Responsibility Principle. Interfaces describe what something can do, not what something is. On the other side, abstract base classes should be used when you're defining the essential core of some thing. Inheritors are the abstract class and it would be wrong to be it and anything else.

This approach guides people to correctly using the code by communicating a better mental view of the design. Further, because it uses a better model, future changes are more likely to work nicely (how many times have you needed to add functionality to an interface, but couldn't because it was an interface?).

Answer 2

A base class will allow you to share mutual functionality. In your example, there is not a huge difference. However imagine you have more than one method on your class.

public abstract class MyBaseClass
{
   public virtual void DoThat()
   {
      //do something cool
   }

   public abstract void DoThis();
}

If you had implemented this on a concrete using an interface, not an abstract class, then you would have to have written the functionality for both methods.

If you use an abstract class or inherit from another class then you only need to write the code for DoThis().

DoThat() already does something cool, there is no reason to rewrite it on every concrete implementation. As it's virtual though, if you need to override it then you can.

Answer 3

Three possible scenarios:

1. You inherit from a base class when you do want to extend and/or refine that base class' current behaviour.

2. You implement an interface when you do want your class to meet the contract specified by that interface.

3. Otherwise, you can perfectly do neither one nor the other.

In both three cases you end up with a class implementing the same methods. It's entirely a matter of semantics.