When would you use an Abstract class?

When to use Abstract and when to use Interface

1.   If you are creating something that provides common functionality to unrelated classes, use an interface

2.   Abstract classes allow you to provide default functionality for the subclasses.

3.   If you are creating something for objects that are closely related in a hierarchy, use an abstract class

4.   If the base class will be changing often and an interface was used instead of an abstract class, we are going to run into problems. Once an interface is changed, any class that implements that will be broken. Now if it’s just you working on the project, that’s no big deal. However, once your interface is published to the client, that interface needs to be locked down. At that point, you will be breaking the clients code

5.   Compared to interfaces abstract classes can have implementation. Without implementation an abstract class does the same as an interface but C# allows you to inherit from / implement multiple interfaces but inherit from one base class only.

6.   An interface once deployed is "frozen" - you must not change a deployed interface. If you change an interface you break binary compatibility but you can extend an abstract class as long as you don't change method signatures.

Use an abstract class

When creating a class library which will be widely distributed or reused—especially to clients, use an abstract class in preference to an interface; because, it simplifies versioning. This is the practice used by the Microsoft team which developed the Base Class Library. (COM was designed around interfaces.)

Use an abstract class to define a common base class for a family of types.

Use an abstract class to provide default behavior.

Subclass only a base class in a hierarchy to which the class logically belongs.

Use an interface

When creating a standalone project which can be changed at will, use an interface in preference to an abstract class; because, it offers more design flexibility.

Use interfaces to introduce polymorphic behavior without subclassing and to model multiple inheritance—allowing a specific type to support numerous behaviors.

Use an interface to design a polymorphic hierarchy for value types.

Use an interface when an immutable contract is really intended.

A well-designed interface defines a very specific range of functionality. Split up interfaces that contain unrelated functionality.

When you want a base class which should not be instantiated and have some common functionality for every class well as different implementation of a method in derived classes for other methods.
For more information you can see

Abstract Class in C# with Example

Basically Abstract class should be used for 'is-a' relationship and Interface should be used for 'has-a' relationship.
If we want to retrict all the subclasses must have certain functionality, then Abstract class with implementation is recomended. So, overriding already implemented member in the subclasses is not a good practice here.

In a particular class, where there are more behaviours that will get change during runtime, then implementing from multiple interfaces are recommended.

I think the most of the answers above are explained the need for Base/derived classes. In my knowledge the abstract class will contain a concrete method which can not be override by the derived classes. Means if you DON'T want to change one basic business rule(the concrete method) defined in the base (abstract) class by the derived classes, then go for abstract class with the concrete method.

As Ricky says. When two classes share the same properties or method the common denominator is your abstract class. There are many benefits aside from this. but when you have to change a property type for e.g.  D.on't R.epeat Y.ourself

Let’s put it like this, let’s say you have a standard employee hierarchy you want to implement, you are going to have for e.g. a Chairman, Directors, Managers, Associates etc. Each of these is a type of employee so your employee class will be the abstract base class which will contain all of the common shared properties, methods etc. Now when you create your Manager class for e.g. it will inherit from the abstract Employee class and automatically have all of the various properties, methods etc that Employee has. If you think about it it doesn't make sense to create an instance of an Employee class but it does to create an instance of say the Manager class or an Associate class which makes it easy to know when to have a abstract class, just ask yourself does it make sense to instantiate X type of class and if the answer is no you are probably better off having it as an abstract class, this is not a hard and fast rule but a good guide. Another benefit of having an abstract base class is if you need to make a change you only need to make it in one place. This is only a very basic explanation and doesn’t cover all of the rules and reasons for abstract classes but I hope it sheds a little light on it for you.

This may help you a little more.

http://www.codeproject.com/KB/cs/jmabstractclasses.aspx

Good luck

Ricky

Use Abstract class when there is a 'IS-A' relationship between classes. For example, Lion is a Animal, Cat is an Animal. So, Animal can be an abstract class with common implementation like no. of legs, tail etc.

Hi Satya,

Compared to interfaces abstract classes can have implementation. Without implementation an abstract class does the same as an interface but C# allows you to inherit from / implement multiple interfaces but inherit from one base class only.

An interface once deployed is "frozen" - you must not change a deployed interface. If you change an interface you break binary compatibility but you can extend an abstract class as long as you don't change method signatures.

Regards,
Torsten.