"Abstract class" and "interface" are similar concepts, with interface being the more abstract of the two. One differentiating factor is that abstract classes provide method implementations for derived classes when needed. In C#, however, this differentiating factor has been reduced by the recent introduction of extension methods, which enable implementations to be provided for interface methods. Another differentiating factor is that a class can inherit only one abstract class (i.e., there is no multiple inheritance), but it can implement multiple interfaces. This makes interfaces less restrictive and more flexible. So, in C#, when should we use abstract classes instead of interfaces with extension methods?

A notable example of the interface + extension method model is LINQ, where query functionality is provided for any type that implements IEnumerable via a multitude of extension methods.

Extension methods do not quite solve the problem that the abstract classes solve, so the reason is no different than it is in Java or some other similar single-inheritance language.
–
JobDec 13 '11 at 16:09

3

The need for abstract class method implementations has not been reduced by extension methods. Extension methods cannot access private member fields, nor can they be declared virtual and be overridden in derived classes.
–
zooone9243Aug 25 '12 at 15:25

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.

But same thing can be done with Interfaces and extension methods. There the methods you are defining in the abstract base class like Do() will be defined as an extension method. And the methods left for derived classes' definition like DoThis() will be member of the main Interface. And with interfaces, you can support multiple implementations/inheritance. And see this- odetocode.com/blogs/scott/archive/2009/10/05/…
–
GulshanJan 31 '11 at 10:53

@Gulshan: Because a thing can be done in more than one way does not make the chosen way invalid. There is no advantage in using interfaces. The abstract class itself is the interface. You don't need interfaces to support multiple implementations.
–
ThomasXDec 13 '11 at 14:06

Also, there can be disadvantages to the interface + extension model. Take the Linq library, for instance. It's great, but if you need to use it only once in that code file, the full Linq library will be available in IntelliSense on EVERY IEnumerable in your code file. This can slow IDE performance considerably.
–
KeithSFeb 2 '12 at 19:22

-1 because you have not demonstrated any way in which abstract classes are a better fit for Template Method than interfaces
–
Benjamin HodgsonJan 28 at 21:50

I just realized, that I haven't used abstract classes (at least not created) in years.

Abstract class is a somewhat strange beast between interface and implementation. There is something in abstract classes which tingles my spider-sense. I would argue, one should not "expose" the implementation behind interface in any way (or make any tie-ins).

Even if there is a need for common behavior between classes implementing an interface, I would use an independent helper class, rather than an abstract class.

-1: I'm not sure how old you are, but you might want to learn design patterns, particularly the template method pattern. Design patterns will make you a better programmer and they'll end your ignorance of abstract classes.
–
Jim G.Feb 23 '11 at 18:00

Same about the tingling sensation. Classes, the first and foremost feature of C# and Java, are a feature for creating a type and immediately chaining it forever to one implementation.
–
Jesse MillikanFeb 24 '11 at 17:03

Applying extension methods to an interface is useful for applying common behaviour across classes that may share only a common interface. Such classes may already exist and be closed to extensions via other means.

For new designs I would favour the use of extension methods on interfaces. For a hierarchy of Types, extension methods provide a means to extend behaviour without having to open the entire hierarchy for modification.

However, extension methods are unable to access private implementation, so at the top of a hierarchy, if I need to encapsulate private implementation behind a public interface then an abstract class would be the only way.

No, it's not the only safe way. There is another safer way. That is the extension methods. Clients will not be infected at all. That's why I have mentioned interfaces + extension methods.
–
GulshanJan 31 '11 at 11:36

@Ed James I think "less powerful" = "more flexible" When would you choose a more powerful abstract class instead of more flexible interface?
–
GulshanJan 31 '11 at 12:26

@Ed James In asp.mvc extension methods were used from the very beginning. What do you think about that?
–
GulshanFeb 23 '11 at 11:08

Abstract classes work by inheritance. Being just special base classes, they model some is-a-relationship.

For example, a dog is an animal, thus we have

class Dog : Animal { ... }

As it doesn't make sense to actually create a generic all-animal (what would it look like?), we make this Animal base class abstract - but it's still a base class. And the Dog class doesn't make sense without being an Animal.

Interfaces on the other hand are a different story. They don't use inheritance but provide polymorphism (which can be implemented with inheritance too). They don't model an is-a relationship, but more of a it does support.

Take e.g. IComparable - an object that supports being compared with another one.

The functionality of a class does not depend on the interfaces it implements, the interface just provides a generic way of accessing the functionality. We could still Dispose of a Graphics or a FileStream without having them implement IDisposable. The interface just relates the methods together.

In principle, one could add and remove interfaces just like extensions without changing the behaviour of a class, just enriching the access to it. You cannot though take away a base class as the object would become meaningless!

When would you choose to keep a base class abstract?
–
GulshanJan 31 '11 at 12:28

1

@Gulshan: If it does - for some reason - not make sense to actually create an instance of the base class. You can "create" a Chihuahua or a white shark, but you cannot create an animal without further specialization - thus you would make Animal abstract. This enables you to write abstract functions to be specialized by the derived classes. Or more in programming terms - it does probably make no sense to create a UserControl, but as a Buttonis a UserControl, so we have the same kind of class/baseclass relationship.
–
DarioFeb 1 '11 at 21:05

if you have abstract methods, than you have abstract class. And abstract methods you have when there is no value for implementing them (like "go" for animal). And of course sometimes you don't want to allow objects of some general class, than you make it abstract.
–
DainiusJun 15 '11 at 11:33

Classes use a certain kind of inheritance, while interfaces use a different kind of inheritance.

Both kinds of inheritance are important and useful, and each one has its pros and cons.

Let's start at the beginning.

The story with interfaces starts a long while back with C++. In the mid-1980s, when C++ was developed, the idea of interfaces as a different kind of type was not yet realized (it would come in time).

C++ only had one kind of inheritance, the kind of inheritance used by classes, called implementation inheritance.

To be able to apply the GoF Book recommendation: "To program for the interface, and not for the implementation", C++ supported abstract classes and multiple implementation inheritance to be able to do what interfaces in C# are capable (and useful!) of doing.

C# introduces a new kind of type, interfaces, and a new kind of inheritance, interface inheritance, to offer at least two different ways to support "To program for the interface, and not for the implementation", with one important caveat: C# only supports multiple inheritance with interface inheritance (and not with implementation inheritance).

So, the architectural reasons behind interfaces in C# is the GoF recommendation.