Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm strugging to know when to use a base class with Polymorphism or an interface.

Providing my object exposes DoThis() then I can't see why it matters if it's an interface of a base class.

Please consider the following

public void MyMethod()
    var myObject = new MyObject();

In regards to MyObject, I could have created it in 2 ways

Approach 1

public class MyObject : IMyInterface
    public void DoThis()

Approach 2

public class MyObject : MyBaseObject
    public override void DoThis()

From what I can see, both of these implementations achieve the same thing.

The issue could be my example is too simple/contrived but, is there a way to know when to use one approach over the other? In my example above, I would guess the answer is preference? I've not done any big projects before and so I'm guessing that one isn't as extendible but I don't know why I think that!

share|improve this question

marked as duplicate by gnat, MichaelT, Bart van Ingen Schenau, Dan Pichelman, GlenH7 Feb 13 '14 at 14:47

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Did you even try to study what interface and abstract class is? – Euphoric Feb 12 '14 at 11:26
Some languages like C# only permit one base class to be inherited at a time whilst multiple interfaces can be implemented. – Robbie Dee Feb 12 '14 at 11:46
My rule of thumb: If you want to provide some common functionality accessible to a subset of classes, use a base class. If you want to define the expected behavior of of a subset of classes, use an interface. – Roger Feb 12 '14 at 14:54
One important difference is that you can't add methods to a public interface, but you can add methods to a public abstract base class. – CodesInChaos Feb 12 '14 at 16:02
up vote 1 down vote accepted

A base class will allow you to share mutual functionality. In your example, there is not a huge difference. However imagine you have more than one method on your class.

public abstract class MyBaseClass
   public virtual void DoThat()
      //do something cool

   public abstract void DoThis();

If you had implemented this on a concrete using an interface, not an abstract class, then you would have to have written the functionality for both methods.

If you use an abstract class or inherit from another class then you only need to write the code for DoThis().

DoThat() already does something cool, there is no reason to rewrite it on every concrete implementation. As it's virtual though, if you need to override it then you can.

share|improve this answer
However, beware the Fragile Base Class Problem. You could achieve the same thing by moving the functionality of DoThat to a static DefaultDoThat method and calling it from the classes that implement the interface. Instance variables can be passed to DefaultDoThat as arguments. Classes that want a different implementation can simply not call DefaultDoThat (or call it and do additional work before/after it.) In my opinion implementation inheritance should be avoided except when you want a finite number of subclasses. – Doval Feb 12 '14 at 19:44

In C#, there are two (major) things that differ between interfaces and abstract classes:

  1. You can implement more than one interface, but only one class.
  2. To be able to do that, you can't do some things in an interface that you can do on the base class - most commonly, implement any sort of default/common implementations.

One new caveat to this is that in .net 3.5 and later, you can create extension methods for interfaces. This can provide common or default behavior for instance methods, but not other members.

Most people will say to make an interface until you need the capabilities of an abstract base type. I urge a different approach:

Certainly there will be times when the functional differences will force your hand, but the choice also guides users in the use of your types. Use interfaces when you are conceptually describing a trait, or some property to be implemented. Something that can conceivably be implemented alongside other interfaces without violating the Single Responsibility Principle. Interfaces describe what something can do, not what something is. On the other side, abstract base classes should be used when you're defining the essential core of some thing. Inheritors are the abstract class and it would be wrong to be it and anything else.

This approach guides people to correctly using the code by communicating a better mental view of the design. Further, because it uses a better model, future changes are more likely to work nicely (how many times have you needed to add functionality to an interface, but couldn't because it was an interface?).

share|improve this answer

Three possible scenarios:

  1. You inherit from a base class when you do want to extend and/or refine that base class' current behaviour.

  2. You implement an interface when you do want your class to meet the contract specified by that interface.

  3. Otherwise, you can perfectly do neither one nor the other.

In both three cases you end up with a class implementing the same methods. It's entirely a matter of semantics.

share|improve this answer
If you inherit from a base class, you also gain access to any non-overrided methods in that class. This is fundamentally different than the other two solutions. It's not semantics at all. The different approaches fulfill vastly different purposes. – Roger Feb 12 '14 at 14:51
Inheriting just to gain access is not a good design guideline. I reaffirm myself, it's mainly semantics. – rucamzu Feb 12 '14 at 14:54
Yes, but you can do MORE than just "gain access" via inheritance. Just because this particular example doesn't demonstrate that doesn't mean that it isn't an available possibility. You CANNOT define functionality via an interface, ergo the two processes are NOT identical, and calling them essentially the same is misleading. – Roger Feb 12 '14 at 14:57
Well, that's true. I wasn't thinking on additional methods you inherit from an hipothetic base class, only on those defined in the final class. Thanks @Roger for pointing this out :) – rucamzu Feb 12 '14 at 15:00
Don't think on efficiency here, for it is dangerous from the point of view of design. Simply use base classes and interfaces, each in those situations for which they're suitable. – rucamzu Feb 12 '14 at 16:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.