Why are interfaces useful?
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?
_"If I can remember the names and signature of the functions which are needed to be implemented, there is no need for them."_ This statement makes me suspect you should look a bit more into the advantages of statically typed languages.
Forget C#, forget Java, forget the language. It's simply thinking in terms of OO. I would encourage you to pick up some reading material from folks like Robert C. Martin, Martin Fowler, Michael Feathers, the Gang of Four, etc., as it will help expand your thinking.
It took me more than two years to really understand what interfaces are good for. My suggestion: study Design Patterns. As most of them rely on interfaces, you will quickly understand why they are so useful.
I agree with all of you about needing interfaces for proper OOP and Design Patterns. I would also suggest trying to code against an API without interfaces, you will understand why they are used then.
An interface is there to define "what" is to be done. The implementation is "how" it is done. Interface helps to have clear boundaries between components, so that different implementations can provide the same functionalities. Multiple inheritance is primarily there to reuse code, which is absolutely not the same intent. Moreover, multiple inheritance was removed in C#/java to avoid well-known pitfalls like the diamond-problem. In short: interface == clean separation between the contract and the implementation. Multiple inheritance == ...code reuse ...but be careful
@qntmfred - Of course! I'm in the process of learning advanced data structures myself.
If you want some hands on, you should try learning a bit about WCF and you will see interfaces in use and why they are important.
Interfaces are already useful in the theoretical sense of the word (think UML). Along the line of what arnaud says it would not be possible to interact with a class if they didn't exist. Basically class = implementation + interface. The interfaces in C# are simply a way of separating the buttons from the electronics of a remote control.
Anyone who has created a custom membership provider in ASP.NET would understand why interfaces are so valuable.
Highly recommend to read 'Head First Design Patterns'. Lots of examples eventually start appreciating interfaces and understand the purpose and benefits of em.
This question seems to have been asked with a total lack of research. Just looking up the concept of an interface, or the programming specific concept on wikipedia would have given a deeper perspective than what is in the opening post.
I remember when I thought implementation inheritance was THE solution for reuse, and languages forbidding multiple inheritance were limiting.
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.
I was just reading "Microsoft creates the problem by not allowing multiple inheritance" and I thought Eric Lippert would have something to say about that.
More relevant to this answer: Eric, you're referring the asker to Code Contracts, but they are woefully incomplete; anything other than the most basic contracts is not enforceable by the static checker. I tried using Code Contract on a small project; I've added hundreds of lines for each and every method specifying everything I could about input and output, and yet, I had to add so many `Assume` calls, for cases like array or enumeration members. After adding everything and seeing the statically verified mess I had, I reverted in source control because it reduced the quality of my project.
@configurator: They are incomplete because they cannot be complete; static program verification with arbitrary contracts is equivalent to solving the Halting Problem. (For example, you could write a code contract that says that the arguments to a method must be a counterexample to Fermat's Last Theorem; but the static verifier is not going to be able to verify that there are no such arguments.) You've got to use it judiciously if you expect the static verifier to complete its work before the heat death of the universe. (If your complaint is that the BCL is insufficiently annotated: I agree.)
I expect it to realize that when one method promises that the results array or enumeration does not contain null, the using method can use the values in places that don't allow nulls. That's the one thing I expected it to do that it didn't, and it was too important to be usable without it; anything else is just a bonus. That said, I know static verification can't be complete, which is why I think it's not a good alternative to rely on for contracts.