When to use an interface instead of an abstract cl

Question

This may be a generic OOP question. I wanted to do a generic comparison between an interface and an abstract class on the basis of their usage.

When would one want to use an interface and when would one want to use an abstract class?

Answer 1

OK, having just "grokked" this myself - here it is in layman's terms (feel free to correct me if I am wrong) - I know this topic is oooooold, but someone else might stumble across it one day...

Abstract classes allow you to create a blueprint, and allow you to additionally CONSTRUCT (implement) properties and methods you want ALL its descendants to possess.

An interface on the other hand only allows you to declare that you want properties and/or methods with a given name to exist in all classes that implement it - but doesn't specify how you should implement it. Also, a class can implement MANY interfaces, but can only extend ONE Abstract class. An Interface is more of a high level architectural tool (which becomes clearer if you start to grasp design patterns) - an Abstract has a foot in both camps and can perform some of the dirty work too.

Why use one over the other? The former allows for a more concrete definition of descendants - the latter allows for greater polymorphism. This last point is important to the end user/coder, who can utilise this information to implement the A.P.I(nterface) in a variety of combinations/shapes to suit their needs.

I think this was the "lightbulb" moment for me - think about interfaces less from the author's perpective and more from that of any coder coming later in the chain who is adding implementation to a project, or extending an API.

Answer 2

If you are looking at java as OOP language,

"interface does not provide method implementation" is no longer valid with Java 8 launch. Now java provides implementation in interface for default methods.

In simple terms, I would like to use

interface: To implement a contract by multiple unrelated objects. It provides "HAS A" capability.

abstract class: To implement the same or different behaviour among multiple related objects. It establishes "IS A" relation.

Oracle website provides key differences between interface and abstract class.

Consider using abstract classes if :

1. You want to share code among several closely related classes.
2. You expect that classes that extend your abstract class have many common methods or fields, or require access modifiers other than public (such as protected and private).
3. You want to declare non-static or non-final fields.

Consider using interfaces if :

1. You expect that unrelated classes would implement your interface. For example,many unrelated objects can implement Serializable interface.
2. You want to specify the behaviour of a particular data type, but not concerned about who implements its behaviour.
3. You want to take advantage of multiple inheritance of type.

Example:

Abstract class ( IS A relation)

Reader is an abstract class.

BufferedReader is a Reader

FileReader is a Reader

FileReader and BufferedReader are used for common purpose : Reading data, and they are related through Reader class.

Interface ( HAS A capability )

Serializable is an interface.

Assume that you have two classes in your application, which are implementing Serializable interface

Employee implements Serializable

Game implements Serializable

Here you can't establish any relation through Serializable interface between Employee and Game, which are meant for different purpose. Both are capable of Serializing the state and the comparasion ends there.

Have a look at these posts :

How should I have explained the difference between an Interface and an Abstract class?

Answer 3

When to prefer an abstract class over interface?

1. If one plans on updating a base class throughout the life of a program/project, it is best to allow that the base class be an abstract class
2. If one is trying to build a backbone for objects that are closely related in a hierarchy, it is highly beneficial to use an abstract class

When to prefer an interface over abstract class?

1. If one is not dealing with a massive hierarchical type of framework, interfaces would be a great choice
2. Because multiple inheritance is not supported with abstract classes(diamond problem), interfaces can save the day

Answer 4

Classes may inherit from only one base class, so if you want to use abstract classes to provide polymorphism to a group of classes, they must all inherit from that class. Abstract classes may also provide members that have already been implemented. Therefore, you can ensure a certain amount of identical functionality with an abstract class, but cannot with an interface.

Here are some recommendations to help you to decide whether to use an interface or an abstract class to provide polymorphism for your components.

• If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created in that way. If a new version of an interface is required, you must create a whole new interface.
• If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
• If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
• If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.

Copied from:
http://msdn.microsoft.com/en-us/library/scsyfw1d%28v=vs.71%29.aspx

Answer 5

I think the most succinct way of putting it is the following:

Shared properties => abstract class.
Shared functionality => interface.

And to put it less succinctly...

Abstract Class Example:

public abstract class BaseAnimal
{
    public int NumberOfLegs { get; set; }

    protected BaseAnimal(int numberOfLegs)
    {
        NumberOfLegs = numberOfLegs;
    }
}

public class Dog : BaseAnimal
{
    public Dog() : base(4) { }
}

public class Human : BaseAnimal 
{
    public Human() : base(2) { }
}

Since animals have a shared property - number of legs in this case - it makes sense to make an abstract class containing this shared property. This also allows us to write common code that operates on that property. For example:

public static int CountAllLegs(List<BaseAnimal> animals)
{
    int legCount = 0;
    foreach (BaseAnimal animal in animals)
    {
        legCount += animal.NumberOfLegs;
    }
    return legCount;
}

Interface Example:

public interface IMakeSound
{
    void MakeSound();
}

public class Car : IMakeSound
{
    public void MakeSound() => Console.WriteLine("Vroom!");
}

public class Vuvuzela : IMakeSound
{
    public void MakeSound() => Console.WriteLine("VZZZZZZZZZZZZZ!");        
}

Note here that Vuvuzelas and Cars are completely different things, but they have shared functionality: making a sound. Thus, an interface makes sense here. Further, it will allow programmers to group things that make sounds together under a common interface -- IMakeSound in this case. With this design, you could write the following code:

List<IMakeSound> soundMakers = new List<ImakeSound>();
soundMakers.Add(new Car());
soundMakers.Add(new Vuvuzela());
soundMakers.Add(new Car());
soundMakers.Add(new Vuvuzela());
soundMakers.Add(new Vuvuzela());

foreach (IMakeSound soundMaker in soundMakers)
{
    soundMaker.MakeSound();
}

Can you tell what that would output?

Lastly, you can combine the two.

Combined Example:

public interface IMakeSound
{
    void MakeSound();
}

public abstract class BaseAnimal : IMakeSound
{
    public int NumberOfLegs { get; set; }

    protected BaseAnimal(int numberOfLegs)
    {
        NumberOfLegs = numberOfLegs;
    }

    public abstract void MakeSound();
}

public class Cat : BaseAnimal
{
    public Cat() : base(4) { }

    public override void MakeSound() => Console.WriteLine("Meow!");
}

public class Human : BaseAnimal 
{
    public Human() : base(2) { }

    public override void MakeSound() => Console.WriteLine("Hello, world!");
}

Here, we're requiring all BaseAnimals make a sound, but we don't know its implementation yet. In such a case, we can abstract the interface implementation and delegate its implementation to its subclasses.

One last point, remember how in the abstract class example we were able to operate on the shared properties of different objects and in the interface example we were able to invoke the shared functionality of different objects? In this last example, we could do both.

Answer 6

For me, I would go with interfaces in many cases. But I prefer abstract classes in some cases.

Classes in OO generaly refers to implementation. I use abstract classes when I want to force some implementation details to the childs else I go with interfaces.

Of course, abstract classes are useful not only in forcing implementation but also in sharing some specific details among many related classes.