How to decide to choose Abstract class or an Interface

Rule of thumb:
If most of the derived classes really would take advantage of inheriting common behaviour then use the abstract base class, otherwise choose the interface (if you're building a library then use the interface).
:)

The best answer here is the one by C Pallini.

It needs one subtle recommendation: do not use abstract classes where interface can be used.

It looks like the inference from the rule of thumb offered by C Pallini, but it is not.
Sometimes, you need a common behavior for derived classes which you can use polymorphous container. Interface cannot be used here, because late binding is involved. At the same time, you can use the same very abstract class to express a common interface to all of the classes to be passed, say, as a parameter to some other class not related to your hierarchy.

Event if the public/internal set of features matches your goal — don't do it! Why? In this way you would cut yourself from extra flexibility: ability to create another class not related to your existing hierarchy implementing the same interface.

One could also create a "poor virtual" abstract class (a class with method-only members; all of them being abstract), as a logical equivalent of interface (this is how C++ interfaces are implemented). Same thing: don't do it! Interfaces are interfaces: they add extra isolation from implementation. Consider the following example:

IMyInterface {
    void MethodA();
    void MethodM();
}

class MyInterfaceImplementation : IMyInterface {
    public void MethodA() { /*...*/ } //DO NOT prefer this syntax
    void IMyInterface.MethodB() { /*...*/ } //DO prefer this syntax
}

//... why such preference? Let's see:

MyInterfaceImplementation impl = new MyInterfaceImplementation();
IMyInterface intrfHandle = impl; //so far so good
intrfHandle.MethodA(); intrfHandle.MethodB(); //intended use

impl.MethodA(); //allowed, but not for good: unintended use
//will not compile:
//impl.MethodB(); //not accessible from class handle, needs interface handle

The fact that last (commented out) call will not compile is really good, it help isolation of class instances represented by interfaces from implementations, another reason to prefer "interface for interfacing".

—SA

Here[^] is a discussion which might help or at least get you started.

See this CP Articles:Abstract Class Vs Interface[^]
Abstract Class versus Interface[^]
Some more useful links
Should_I_use_an_abstract_class_or_an_interface[^]

Let me try to give an example There is an animal class. You have a move function common to all childs. So you have it in the abstract class and implemented in different child classes like cat, dog etc.., Now say you want a jumping dog, a crawling dog, a swimming dog. oh! you will be ending up overriding move function and create 100s of child classes.

Instead have an interface sa IMove which has a move function.

Implement that move function in different classes like

class Jump:IMove , class Swimm:IMove, class Crawl:IMove (behaviour separation)

Then in your dog class have property say public IMove myMove(){ get; set;}

set the myMove from the caller (dependency Injection/ strategy pattern) For example this.myMove=new Crawl();

In the move function call this.myMove.Move();

All these together called composite pattern. If interested google why to use composite pattern