Are Abstract Classes and Methods Obsolete?

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