Could you please tell me the advantage of using the interface to code?

[mctramp168]

I am a novice of .net, It seems that the interface does not do anything ,could you pls tell me above it? I'll very appreciate you if you give some code for compare(one include interface,the other not using interface) Thanks

[SeMartens]

Hi, since interfaces are nothing .net-specific, you can find them in many languages C#, Java etc. An interface is a desgin pattern to be more formal about, what a class offers to the user of the class. Using interfaces is a method to achieve good system design, higher maintainability and good readibility. You should always use interfaces if you implement interaction between losely coupled components. I will post a link here (shame on me it's Java, but was the fastest I could get): http://java.sun.com/docs/books/tutorial/java/concepts/interface.html[^]. If this is not sufficient, try to find sth. about object-oriented design/architecture/programming. Does this help you? Regards Sebastian

It's not a bug, it's a feature! Check out my CodeProject article Permission-by-aspect. Me in Softwareland.

[DaveyM69]

Interfaces are very useful - even though they don't do anything themselves. A simple example. Imagine you needed to support more than one type of database, say XML and SQLServer. Obviously, you'd have a class for both types with the necessary methods. The methods exposed by each class would be identical - the only difference would be the implementation inside the methods. This gives you three possibilities. 1. Have both classes exposed and call the correct one 2. Have an abstract base Database class that XML and SQLServer classes derrive from 3. Create an IDatabase Interface. 1 is not very flexible and would require the calling code to be closely coupled to your DB classes. If you later needed to add Oracle as an option, all your calling code would have to be changed. 2 is kind of pointless, as the base class would never actually be used. 3 gives the perfect solution. XML : IDatabse and SQLServer : IDatabase Now you can call the methods on an IDatabase instance, and whether XML or SQLServer are called can be decided elsewhere - the calling code will never need to be changed and can be easily extended to support others in future.

Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)

[Alan Balkany]

Another benefit of interfaces is that they identify/factor out common behavior among very different classes. This lets you pass objects of two very different classes that implement interface X to the same parameter in a method that takes an interface X parameter. This lets you reuse that method's code for different classes that implement this interface. This mechanism also helps make your code more modular. In the above example, the method doesn't know any details about the objects it receives as a parameter, except that they implement interface X. So any non-interface-X changes to the classes passed as a parameter are guaranteed to not impact the method.

[Guffa]

In short an interface is a contract for an ability that you can implement in a class. For example, a class can implement the IComparable interface, which means that you can compare one instance of the class to another. A method like List.Sort can then sort a list of instances, without the need to know anything at all about the class other than it implements the interface. To make a method more flexible you can accept parameters of an interface type instead of a specific class. If for example your method needs to loop through some items, it can accept a parameter of the interface type IEnumerable instead of an array. Then your method can be used with any class that implements the interface, like an array, a List, a Queue, a Dictionary.KeyCollection, et.c. You can also create interfaces to use between your own classes.

Despite everything, the person most likely to be fooling you next is yourself.

[CodingYoshi]

An interface is an aspect. For example, all cars have a steering wheel (aspect of steering) but when the steering happens the implementation differs with every manufacturer or they might not, however, a user does not care what happens in the middle. The user only cares about the interface (steering) and the outcome (wheels to turn). Interfaces in programming serve the same purpose. Different classes can have their own implementation but the input and output will always be the same. Consider this: public class Customer { Save() { ISaver saver = new DBSaver(); saver.Insert(this); // Here we are asking an implementation of Insert which inserts to the database. } } internal class DBSaver : ISaver { public void Save(Customer c) { // Here the implementation is to save to DB } } Now if your users decide they do not want to save to databases anymore but want to save to a flat file (not sure why they would do this but who cares), all you have to do is write another class which implements the interface, unit test it and then change only one line of code in Customer as below: public class Customer { Save() { ISaver saver = new FlateFileSaver(); // Only this line is changed saver.Insert(this); // Here we are asking an implementation of Insert which inserts to the flat file. } } That is it and you are good to go. Your UI is still calling CustomerObject.Save() but something different is happening--polymorphism. There are many other advantages to using Interfaces but this is the basic idea. Sometimes it also helps layout the foundation (blueprint foundation) for something. For example, I do not know how to make a good container class but if I implement the IList interface provided by .NET then I will have a good container will all the appropriate methods. Of course, you have to write good implementation because even if you write garbage inside the implementation that is what will get carried out.