Why are interfaces useful?

Question

I have been studying and coding in C# for some time now. But still, I can't figure the usefulness of Interfaces. They bring too little to the table. Other than providing the signatures of function, they do nothing. If I can remember the names and signature of the functions which are needed to be implemented, there is no need for them. They are there just to make sure that the said functions(in the interface) are implemented in the inheriting class.

C# is a great language, but sometimes it gives you the feeling that first Microsoft creates the problem (not allowing multiple inheritance) and then provides the solution, which is rather a tedious one.

That's my understanding which is based on limited coding experience. What's your take on interfaces? How often you make uses of them and what makes you do so?

Answer 1

They are there just to make sure that the said functions (in the interface) are implemented in the inheriting class.

Correct. That's a sufficiently awesome benefit to justify the feature. As others have said, an interface is a contractual obligation to implement certain methods, properties and events. The compelling benefit of a statically typed language is that the compiler can verify that a contract which your code relies upon is actually met.

That said, interfaces are a fairly weak way to represent contractual obligations. If you want a stronger and more flexible way to represent contractual obligations, look into the Code Contracts feature that shipped with the last version of Visual Studio.

C# is a great language, but sometime it gives you the feeling that first Microsoft creates the problem(not allowing multiple inheritance) and then provides the solution, which is rather a tedious one.

Well I'm glad you like it.

All complex software designs are a result of weighing conflicting features against each other, and trying to find the "sweet spot" that gives large benefits for small costs. We've learned through painful experience that languages that permit multiple inheritance for the purposes of implementation sharing have relatively small benefits and relatively large costs. Permitting multiple inheritance only on interfaces, which do not share implementation details, gives many of the benefits of multiple inheritance without most of the costs.

Answer 2

So in this example, the PowerSocket doesn't know anything else about the other objects. The objects all depend on Power provided by the PowerSocket, so they implement IPowerPlug, and in so doing they can connect to it.

Interfaces are useful because they provide contracts that objects can use to work together without needing to know anything else about each other.

Answer 3

Other than providing the signatures of function, they do nothing. If I can remember the names and signature of the functions which are needed to be implemented, there is no need for them

The point of interfaces is not to help you remember what method to implement, it is here to define a contract. In foreach P.Brian.Mackey example (which turns out to be wrong, but we don't care), IEnumerable defines a contract between foreach and any enumerable thing. It says : "Whoever you are, as long as you stick to the contract (implement IEnumerable), I promise you I'll iterate over all your elements". And, that is great (for a non dynamic language).

Thanks to interfaces you can achieve very low coupling between two classes.

Answer 4

Interfaces are the best way to maintain well decoupled constructs.

When writing tests, you will find that concrete classes will not work in your test environment.

Example: You want to test a class that depends on a Data Access Service class. If that class is talking to a web service, or database -- your unit test will not run in your test environment ( plus it has turned into an integration test ).

Solution? Use an Interface for your Data Access Service and Mock that interface so you can test your class as a unit.

On the other hand, WPF & Silverlight do not play at all with Interfaces when it comes to binding. This is a pretty nasty wrinkle.

Answer 5

Interfaces are the backbone of (static) polymorphism! The interface is what matters. Inheritance would not work without interfaces, as subclasses basically inherit the already implemented interface of the parent.

How often you make uses of them and what makes you do so ??

Pretty often. Everything that needs to be pluggable is an interface in my applications. Often times you have otherwise unrelated classes that need to provide the same behaviour. You can't solve such problems with inheritance.

Need different algorithms to perform operations on the same data? Use an interface (see strategy pattern)!

Do you want to use different list implementations? Code against an interface and the caller does not need to worry about the implementation!

It's been considered a good practice (not only in OOP) to code against interfaces for ages, for one single reason: It's easy to change an implementation when you realize it does not fit your needs. It's pretty cumbersome if you try to achieve that only with multiple inheritance or it boils down to creating empty classes in order to provide the necessary interface.

Answer 6

You have probably used foreach and found it to be a pretty useful iteration tool. Did you know that it requires an interface to function, IEnumerable?

That's certainly a concrete case speaking to the usefulness of an interface.

Answer 7

Interfaces are to coding objects like a plug is to household wiring. Would you solder your radio directly to your house wiring? How about your vacuum cleaner? Of course not. The plug, and the outlet it fits into, form the "interface" between your house wiring and the device that needs the power from it. Your house wiring needs to know nothing about the device other than it uses a three-prong grounded plug and requires electrical power at 120VAC <=15A. Conversely, the device requires no arcane knowledge of how your house is wired, other than that it has one or more three-prong outlets conveniently located that provide 120VAC <=15A.

Interfaces perform a very similar function in code. An object can declare that a particular variable, parameter or return type is of an interface type. The interface can't be instantiated directly with a new keyword, but my object can be given, or find, the implementation of that interface that it will need to work with. Once the object has its dependency, it doesn't have to know exactly what that dependency is, it just has to know it can call methods X, Y and Z on the dependency. Implementations of the interface don't have to know how they will be used, they just have to know they will be expected to provide methods X, Y and Z with particular signatures.

Thus, by abstracting multiple objects behind the same interface, you provide a common set of functionality to any consumer of objects of that interface. You don't have to know the object is, for example, a List, a Dictionary, a LinkedList, an OrderedList, or whatever. Because you know all of these are IEnumerables, you can use the methods of IEnumerable to go through each element in these collections one at a time. You don't have to know that an output class is a ConsoleWriter, a FileWriter, a NetworkStreamWriter, or even a MulticastWriter that takes other types of writers; all you have to know is that they're all IWriters (or whatever), and thus they have a "Write" method that you can pass a string into, and that string will be output.

Answer 8

While it clearly is a treat for the programmer (at first, at least) to have multiple inheritance, this is an almost trivial omission, and you should (in most cases) not rely on multiple inheritance. The reasons for this are complex, but if you really want to learn about it, consider the experience from the two most famous (by TIOBE index) programming languages that support it: C++ and Python (3rd and 8th respectably).

In Python, multiple inheritance is supported, yet is almost universally misunderstood by programmers and to state that you know how it works, means to read and understand this paper on the topic: Method Resolution Order. Something else, that happend in Python, is that interfaces sort-of-got into the language - Zope.Interfaces.

For C++, google "diamond hierarchy C++" and behold the ugliness that is about to cover you. C++ pros know how to use multiple inheritance. Everybody else is usually just playing around without knowing what the results will be. Another thing that shows how useful are interfaces is the fact, that in many cases a class might need to override completely its parent's behavior. In such cases, the parent implementation is unnecessary and only burdens the child class with the memory for the parent's private variables, which might not matter in the C# age, but matters when you do embedded programming. If you use an interface, that problem is nonexistent.

In conclusion, interfaces are, in my opinion, an essential part of OOP, because they enforce a contract. Multiple inheritance is useful in limited cases, and usually only to guys who know how to use it. So, if you are a beginner, you are the one who is treated by the lack of multiple inheritance - this gives you a better chance to not make a mistake.

Also, historically, the idea for an interface is rooted far earlier than Microsoft's C# design specs. Most people consider C# to be an upgrade over Java (in most senses), and guess where C# got its interfaces from - Java. Protocol is an older word for the same concept, and it is way older than .NET.

Update: Now I see I might have answered a different question - why interfaces instead multiple inheritance, but this seemed like the answer you were looking. Besides an OO language should have at least one of the two, and the other answers have covered your original question.

Answer 9

It's difficult for me to imagine clean, object-oriented C# code without the use of interfaces. You use them whenever you wish to enforce the availability of certain functionality without forcing classes to inherit from a specific base class, and this allows your code to have the relevant level of (low) coupling.

I don't agree that multiple inheritence is better than having interfaces, even before we get to arguing that multiple inheritence comes with it's own set of pains. Interfaces are a basic tool for enabling polymorphism and code reuse, what more does one need?

Answer 10

I personally love the abstract class and use it more than an interface. The main difference comes with integrating with .NET interfaces such as IDisposable, IEnumerable and so on... and with COM interop. Also, the interface is a little less effort to write than an abstract class, and a class can implement more than one interface while it can only inherit from one class.

That said, I find that most things I would use an interface for are better served by an abstract class. Pure virtual functions--abstract functions-- allow you to force an implementer to define a function similar to the way an interface forces an implementer to define all of its members.

However, you typically use an interface when you do not want to impose a certain design upon the super class, while you would use an abstract class to have a reusable design that is already mostly implemented.

I have used interfaces extensively with writing plugin environments using the System.ComponentModel namespace. They come quite in handy.

Answer 11

I can say I relate to that. When I first started learning about OO and C# I too didn't get Interfaces. That's ok. We just need to come accross something that will make you appreciate the conveniences of interfaces.

Let me try two approaches. And pardon me for the generalizations.

Try 1

Say you're a native English speaker. You go to another country where English is not the native language. You need help. You need someone who can help you.

Do you ask: "Hey, were you born in the United States?" This is inheritance.

Or do you ask: "Hey, do you speak English"? This is interface.

If you care about what it does, you can rely in interfaces. If you care about what is is, you rely on inheritance.

It's ok to rely on inheritance. If you need someone who speaks English, likes tea and likes soccer, you're better served asking for a Brit. :)

Try 2

Ok, let's try another example.

You use different databases and you need to implement abstract classes to work with them. You'll pass your class to some class from the DB vendor.

public abstract class SuperDatabaseHelper
{
   void Connect (string User, string Password)
}

public abstract class HiperDatabaseHelper
{
   void Connect (string Password, string User)
}

Multiple inheritance, you say? Try that with the above case. You can't. The compiler won't know which Connect method you're trying to call.

interface ISuperDatabaseHelper
{
  void Connect (string User, string Password)
}

interface IHiperDatabaseHelper
{
   void Connect (string Password, string User)
}

Now, there's something we can work with - at least in C# - where we can implement interfaces explicitly.

public class MyDatabaseHelper : ISuperDatabaseHelper, IHiperDatabaseHelper
{
   IHiperDataBaseHelper.Connect(string Password, string User)
   {
      //
   }

   ISuperDataBaseHelper.Connect(string User, string Password)
   {
      //
   }

}

Conclusion

The examples are not the best, but I think it gets the point accross.

You'll only "get" interfaces when you feel the need of them. Until them you'll think they're not for you.

Answer 12

Interfaces by themselves are not very useful. But when implemented by concrete classes you see that it gives you the flexibility to have one or more implementations. The bonus is that the object using the interface do not need to know how the details of the actual implementation go - that's called encapsulation.

Answer 13

There are 2 major reasons:

1. Lack of multiple inheritance. You can inherit from one base class and implement any number of interfaces. That's the only way to "do" multiple inheritance in .NET.
2. COM interoperability. Anything that will need to be used by "older" technologies will need to have interfaces defined.

Answer 14

Use of interfaces helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is a very core concept to object-oriented orthodoxy and I first learned about it when C++ gurus made "pure abstract classes" which are quite equivalent to interfaces.

Answer 15

They are mostly used for code reusability. If you code to the interface you can use a diffrent class that inherits from that interface and not break everything.

Also they are very usefull in webservices where you want to let the client know what a class does (so they can consume it) but dont want to give them the actual code.

Answer 16

A real world implementation:

You can cast an object as the Interface type:

IHelper h = (IHelper)o;
h.HelperMethod();

You can create a list of an interface

List<IHelper> HelperList = new List<IHelper>();

With these objects you can access any of the interface methods or properties. In this manner you can define an interface for your part of a program. And build the logic around it. Then someone else can implement your interface in their Business objects. If the BO's change they can change the logic for the interface components and not require a change to the logic for your piece.

Answer 17

As a young programmer/developer, just learning C# you might not see the usefulness of interface, because you might write your codes using your classes and the code works fine, but in real life scenario, building a scalable, robust and maintainable application involves using some architectural and patterns, which can only be made possible by using interface, example is in dependency injection.

Answer 18

Interfaces lend to plugin-style modularity by providing a mechanism for classes to understand (and subscribe to) certain kinds of messages that your system delivers. I'll elaborate.

In your application, you decide that whenever a form is loaded or reloaded you want all of the things it hosts to be cleared. You define an IClear interface which implements Clear. Additionally, you decide that whenever the user hits the save button that the form should attempt to persist its state. Thus, everything that abides by ISave receives a message to persist its state. Of course, practically speaking, most interfaces handle several messages.

What sets interfaces apart is that common behavior can be achieved without inheritance. The class that implement a given interface simply understands how to behave when issued a command (a command message) or how to respond when queried (a query message). Essentially, the classes in your application understand the messages your application provides. This makes it easier to construct a modular system into which things can be plugged.

In most languages there are mechanisms (like LINQ) for querying things that abide by an interface. This will usually help you eliminate conditional logic because you won't have to tell dissimilar things (that are not necessary derived of the same inheritance chain) how to behave similarly (according to a particular message). Instead, you gather everything that understands a certain message (abides by an interface) and publish the message.

For example, you could replace...

Me.PublishDate.Clear()
Me.Subject.Clear()
Me.Body.Clear()

...with:

For Each ctl As IClear In Me.Controls.OfType(Of IClear)()
    ctl.Clear()
Next

Which effectively sounds a lot like:

Hear ye, Hear ye! Would everyone who understands clearing, please Clear now!

In this way, we can programmatically avoid telling each and every thing to clear itself. And when clearable items are added in the future they simply respond without any additional code.

Answer 19

The following is pseudocode:

class MyClass{

    private MyInterface = new MyInterfaceImplementationB();

    // Code using Thingy 

}

interface MyInterface{

    myMethod();

}

class MyInterfaceImplementationA{ myMethod(){ // method implementation A } }

class MyInterfaceImplementationB{ myMethod(){ // method implementation B } }

class MyInterfaceImplementationC{ myMethod(){ // method implementation C } }

The last classes can be completely different implementations.

Unless multiple inheritance is possible, inheritance imposes the implementation of the parent class making things more rigid. Programming against interfaces on the other hand can allow your code or a framework to be extremely flexible. If you ever come accross a case where you wished you could swap around classes in an inheritance chain you'll understand why.

For example, a framework that provides a Reader originally intended to read data from disk could be re-implemented to do something of the same nature but in a totally different way. Like interpret Morse code for example.