When you need a part of the class to be implemented. The best example I've used is the template method pattern.
public abstract class SomethingDoer
{
public void Do()
{
this.DoThis();
this.DoThat();
}
protected abstract void DoThis();
protected abstract void DoThat();
}
Thus, you can define the steps that will be taken when Do() is called, without knowing the specifics of how they will be implemented. Deriving classes must implement the abstract methods, but not the Do() method.
Extensions methods don't necessarily satisfy the "must be a part of the class" part of the equation. Additionally, iirc, extension methods cannot (appear to) be anything but public in scope.
edit
The question is more interesting than I had originally given credit for. Upon further examination, Jon Skeet answered a question like this on SO in favour of using interfaces + extension methods. Also, a potential downside is using reflection against an object hierarchy designed in this way.
Personally, I am having trouble seeing the benefit of altering a currently common practice, but also see few to no downsides in doing it.
It should be noted that it is possible to program this way in many languages via Utility classes. Extensions just provide the syntactic sugar to make the methods look like they belong to the class.
The difference between the abstract classes and interfaces in your case could allow the developer to well-define the pattern of your design with abstract class create "is a" relationship and interface create "can do" relationship.
Put it this way, if you have a Toy car and it would be not make sense to make them "is a" relationship with Minivan since you can use interface to exhibit toy car specific behaviour like water resistance tolerance.
So you can define like:
public Interface IToyCarResistance
{
int ToleranceLevel { get; }
}
public class ToyCar : Car , IToyCarResistance
{
}
Best Answer
A rule of thumb is that:
If a method should be part of the public API, add it to the interface and update dependencies where necessary (i.e. Abstract and / or Generic class).
Otherwise, implement the method as high up as is needed based on how generic or specific it is.
There's no difference in that case; you don't have to specify an interface twice if the ancestor already implements it, because the interpreter will throw an error if you try to break the contract.
This would only make sense if the child class implements another interface altogether. And this is a strength of interfaces; since you're defining a piece of functionality rather than a specific implementation, you can make any class implement any interface if you wanted to. This is a great help when writing mock classes for testing.