What is the true benefit of using Interfaces?

Question

At a high level, my knowledge of Interfaces is such that:

• They declare methods but do not implement them
• Any class that implements an Interface must implement all of its declared methods

To me, this immediately exposes two major problems:

• Because any implementing class must implement all of its methods, this in effect means an Interface can not be changed once it has been used. Adding or removing methods in the Interface would mean altering every class that uses it. The answer is probably exactly that; that they should never be changed, but how can we guarantee that our design is that stable?

• Suppose the classes that implement the Interface actually use the same logic in their implementations. This is code repetition, making it difficult to maintain. Isn't that the point of base classes and inheritance?

I got to this thinking because I thought I had a good grasp of it. I thought an Interface as a 'bolt on' or 'plug in' to the Class, giving it some extra functionality, whereby the functionality isn't tied to that type of class, for example an Interface might define methods to calculate surface area, but lots of things have a surface area, not just 'shape' or 'building', so it seems reasonable to create a 'bolt on' (Interface) for calculating surface area, yet it's probable that every implementation of that Interface will be the same, so where is the benefit? Is this a fair comment? I'm sure they provide great benefit, I just don't see it yet.

Answer 1

Among the other answers, it's important to note that an interface should usually encapsulate the smallest amount of logic possible to perform related actions. A very simple example:

public IVehicle 
{ 
    void Start();
    void Stop();
    void Accelerate();
    void Decelerate();
    void TurnLeft();
    void TurnRight();
    void Reverse();
}

public interface IAeronauticVehicle : IVehicle
{
    void TakeOff();
    void Land();
    void Ascend();
    void Descend();
}

You could then have

public class Car : IVehicle
{
    // ... implementation ...
}

public class Airplane : IAeronauticVehicle
{
    // ... similar IVehicle implementation
    // ... and then the IAeronauticVehicle implementation

    // You could even nullify certain IVehicle methods that don't apply:
    public void Reverse() 
    {
        throw new NotSupportedException();
    }
}

This is a VERY contrived example, but it illustrates that your IVehicle interface does not need to be concerned with extended properties or methods that may only apply to implementations of IAeronauticVehicle. You can add those later. By doing this, you can extend the functionality of your Airplane class and any code that uses IAeronauticVehicle without changing the base contract defined by IVehicle

A classic example of this is the IEnumerable interface, which defines only a single method GetEnumerator. Any class, regardless of purpose, can implement this interface if it intends to return an enumerable set of items. In doing so, this class instantly becomes usable anywhere IEnumerable is supported. The code that uses your IEnumerable implementation doesn't care about any number of other methods on your class such as FetchRecordsFromDatabase() or ValidateInput() or whatever else your class defines.

Interfaces are not supposed to be all-encompassing, so the issue of having to change the interface should (almost) never come up.

Answer 2

To the first question - interfaces are means for providing loose coupling to your system. One example that might help is the HTTP protocol. It is an interface that allows devices to communicate to each other - but those devices sometimes have nothing in common. You may have PCs, laptops, tablets, smartphones, smart TVs, all kinds of appliances that are running desktop Windows, Linux, Mac, any mobile OS, embedded OS and so on. Even though they are completely different, they share a single interface and they can talk to each other easily.

Another example - the iterator pattern. You certainly have used multiple data structures and the urge to enumerate them has risen. Iterators are an interface that allows you to use the same code on arrays, linked lists, queues, stacks. Thus if you need to change your collection for whatever reason, you may do so without breaking projects on the other end of the world. Note that the collections I just mentioned are implemented in a different way and do not share any code.

To the second question - If your classes really implement a single interface in the same way, there's no reason you shouldn't be using a base class that implements the interface. For instance, consider the following hierarchy picked from .NET:

interface IEnumerable
class Collection : IEnumerable
class ObservableCollection: Collection
class MailAddressCollection: Collection
class KeyedCollection: Collection
... about 40 other children of Collection

(some details omitted for clarity)

As you can see, derived classes that need the same implementation of the interface are derived from a one base class instead of directly from the interface so that no code is repeated.

Answer 3

As for your first problem, it makes perfect sense. If classes implement an interface and the interface changes, you DO have to edit all of them. Otherwise, they aren't staying true to the interface, which means the classes which depend on them implementing the interface breaks.

Interfaces are contracts, the class which implements them is promising other classes that they implement certain functionality. If they don't, the whole point of having the interface in the first place is lost.

Answer 4

Having multiple classes that implements a single interface gives you a nice way to manipulate instantiated objects from those different classes using single method. Just by declaring those with the interface they implement. Instead of writing different methods for each class. This is the first I come with on my head as a benefit ;)