When to use an Abstract Class and When an Interface... Some TIPS

The choice of whether to design your functionality as an interface or an abstract class can sometimes be a difficult one. An abstract class is a class that cannot be instantiated, but must be inherited from. An abstract class may be fully implemented, but is more usually partially implemented or not implemented at all, thereby encapsulating common functionality for inherited classes.

An interface, by contrast, is a totally abstract set of members that can be thought of as defining a contract for conduct. The implementation of an interface is left completely to the developer.

Both interfaces and abstract classes are useful for component interaction. If a method requires an interface as an argument, then any object that implements that interface can be used in the argument. 

Interfaces offer more design flexibility; precisely because, they can be implemented by any class regardless of its type hierarchy. An abstract class can contain an interface plus implementations. This simplifies versioning. An abstract class can be extended by adding new non-abstract methods with default implementations. Also, a convenience method is easily added to an abstract class. On the other end, an interface cannot be modified without breaking its contract with the classes which implement it. Once an interface has been shipped, its member set is permanently fixed. An API based on interfaces can only be extended by adding new interfaces.

Interfaces separate the syntax rather than the semantic contract from the implementation. Classes can be designed to decouple the semantic contract from the implementation. For example, abstract classes can be separated in a different assembly than their concrete implementations. A C# class inherits from a single class. Therefore, by inheriting from an abstract class, the derived class has used up its ability to participate in a meaningful type hierarchy. On the other hand, a class can implement (inherit from) any number of interfaces. And, it can still inherit from an abstract class which makes sense.

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.

Difference between abstract classes and interfaces.

Abstract class	Interface
Derived classes exhaust their single base class inheritance option.	Classes can implement multiple interfaces without using up their base class option. But, there are no default implementations.
Cannot be instantiated except as part of subclasses. Only derived classes can call an abstract class constructor.	Cannot be instantiated.
Defines abstract member signatures which derived classes must implement. Otherwise, the derived class itself will be abstract.	Defines abstract member signatures—all of which—implementing classes must implement. Otherwise, a compiler error results.
New non-abstract members may be added that derived classes will inherit without breaking version compatibility.	Extending an interface with new members breaks version compatibility.
Optionally, provide default (virtual) member implementation.	All members are virtual and cannot provide implementations.
Can include data fields.	Cannot include data fields. However, abstract properties may be declared.