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.
1. Singleton
You restrict the number of instances because the constructor will be private meaning only static methods can create instances of that class (there are other dirty tricks actually to accomplish that but let's not get carried away).
Creating a class that will have only 2 or 3 instances is perfectly feasible. You should be using singleton whenever you feel the necessity to have only one instance of that class in the entire system. That usually happens to classes that have a 'manager' behavior.
If you want to learn more about Singletons you can start in Wikipedia and particularly for C++ in this post.
There is definitely some good and bad things about this pattern but this discussion belongs somewhere else.
2. Abstract Classes
Yes, that's right. Only a single virtual method will mark the class as abstract.
You'll be using those kind of classes when you have a bigger class hierarchy in which the top classes should not really be instantiated.
Let's supposed you're defining a Mammal class and then inheriting it to Dog and Cat. If you think about it, there's no much sense to have a pure instance of a Mammal since you first need to know what kind of Mammal it really is.
Potentially there's a method called MakeSound() that will only make sense in the inherited classes but there's no common sound that all mammals can make (It's just an example not trying to make a case for mammal's sounds here).
So that means Mammal should be an abstract class since it will have some common behavior implemented to all mammals but it's not really supposed to be instantiated. That's the basic concept behind abstract classes but there's definitely more to it that you should learn.
3. Interfaces
There are no pure interfaces in C++ in the same sense that you have in Java or C#. The only way to create one is by having a pure abstract class which mimics most of the behavior you want from an interface.
Basically the behavior you're looking for is to define a contract where other objects can interact with without caring about the underlying implementation. When you make a class purely abstract it mean all implementation belongs somewhere else so the purpose of that class is only about the contract it defines. This is a very powerful concept in OO and you should definitely look more into it.
You can read about the interface specification for C# in MSDN to have a better idea:
http://msdn.microsoft.com/en-us/library/ms173156.aspx
C++ will provide the same kind of behavior by having a pure abstract class.
Best Answer
Technically, the differences aren't really significant but, conceptually, they are entirely different things and that leads to the technical differences others have mentioned.
An abstract superclass is exactly what it sounds like, it's a common type that is shared by many other types, like Cats and Dogs are Animals.
An interface is also exactly what it sounds like, it's an interface through which other classes can communicate with the object. If you want to make a Cat Walk, you're ok, cause Cat implements a CanWalk interface. Same for a Lizard, though they walk very differently. A Snake, on the other hand, does not implement CanWalk, so you can't tell it to Walk. Meanwhile, Lizard and Snake (or possibly more explicit subclasses -- I'm not an expert) might both shed their skin, and thus implement CanShed, while a Cat couldn't do that.
But they're all still Animals and have some common properties, like whether they're alive or dead.
This is why all methods on an interface must be implemented as public (or explicitly, in C#). Cause what's the point in an interface that's hidden from the class interfacing with the object? It's also why you can have multiple interfaces to an object, even when a language doesn't support multiple inheritance.
To go back to your question, when you look at it this way, there's very rarely a reason to have an entirely abstract superclass.