When are interfaces needed?

Question

(In the context of .NET for what its worth)

I tend to not use inheritance and rarely use interfaces. I came across someone who thinks interfaces are the best thing since spit. He uses them everywhere. I don't understand this and hence the questions that follow. I just want a check on my understanding of interfaces.

If you are using interfaces everywhere, I'm assuming you can predict the future, your app requirements are nailed down and nothing will ever change in your app. For me, during early development especially, interfaces become a drag. The app is very dynamic through its life. If you need to subtract or add members to the interface, lots of stuff will break. The guy above says he creates another interface to handle the new member(s). Nothing breaks.

Isn't that composition? Why not use composition without interfaces? More flexible.

How does he handle the case where a member must be subtracted from the interface? Basically he doesn't. Things just break and that is great because now you can see all of the affected areas and fix them. Instead of figuring out more elegantly where all of the related code paths are, we should just rip out parts of classes through brute force?

I think of a software application as a graph. A complete graph is the worst case, having n(n-1)/2. This means every class talks to every class. A confusing spider web. n-1 is the best, in which their is a strict hierarchy of communication. Adding another interface just to compensate for a new needed member adds a vertici to the graph, which means more edges and a stronger realization of the n(n-1)/2 equation. Composition without interfaces is more like mixins. Only select classes use particular methods. With an interface, all classes are forced to use members, even if they don't need them. The composition/mixin approach doesn't add new unneeded edges.

Answer 1

This person sound like he misunderstood the concept of programming to an interface. It doesn't refer to programming using only the interface keyword in the .Net/Java or class with nothing but pure virtual functions in C++, The interface that are referred to in that principle are a high-level construct that encapsulates the low-level ones of a system. Like with multiplication, it encapsulates the idea of adding a number to itself a specific quantity of repetitions. But when we say 3 * 2 we don't care if it's 3 + 3, 2 + 2 + 2 or (2 + 2) + 2 where the part in parentheses is cached. So long as we receive a 6 from it.

As a matter of fact the concept of interfaces can be filled by an interface or abstract class or a combination of these as is the case with many of the GoF patterns. It's just that the interface keyword kind of clouds the water with ambiguity.

It's funny. This guy's kind of thinking is probably what's spawned comments such as the ones centering around StackOverflow episode #38.

Answer 2

Interfaces help you keep the dependencies on the abstractions.

Code that uses the interface only depends on the interface, so you know that there are no artificial dependencies on the details. This gives you lots of freedom as far as changing code in the future, since you know exactly what should & shouldn't break when you 'fix' a bug or refactor.

In my opinion, it's the essence of good code design.

Answer 3

According to wikipedia,

The primary usage of polymorphism in industry (object-oriented programming theory) is the ability of objects belonging to different types to respond to method, field, or property calls of the same name, each one according to an appropriate type-specific behavior. The programmer (and the program) does not have to know the exact type of the object in advance, and so the exact behavior is determined at run time (this is called late binding or dynamic binding).

That's what makes interfaces so useful.

"The guy above says he creates another interface to handle the new member(s). Nothing breaks."

I'm just guessing here, but it sounds like this guy comes from an old school COM background (I could be wrong, of course!). Makes me cringe to think of all of the code I've worked on where I've seen things like this:

• IWidgetManager
• IWidgetManager2
• IWidgetManager3

That's not a good way to work with interfaces. In my experience, I've seen both extremes: fear of changing interfaces to the point where new interfaces are created whenever new members are added, or not using interfaces at all and having a product that suffers from a high degree of coupling. You need to find a good balance. It isn't always the end of the world to change an interface.

What is the size of the project you're working on? It can be hard to see the benefit of interfaces if it is a relatively small size project. If, on the other hand, it's a project with several hundred thousand lines of code and is composed of many modules, the benefits become far more apparent.