What is the Purpose of Interface?

What is the purpose of Interfaces? IMHO, it's just a collection of properties, method and events which can be used over and over again by different classes.
It;s no different than declaring the needed method or property in the classes separately rather than using Interface (because in Interface, you have to write the inner working in each classes implementing the interface). Is there a case where an interface comes in handy (I mean cases where Interfaces are absolutely necessary, without them the program won't work)? thanks

An interface is like a contract. You must implement all the methods/properties/events or not us the interface at all. A normal class (inherited) has no way of forcing such a contract.

This comes in handy when you want two applications to talk. The other application just needs to know that you have implemented the interface - nothing more. So it can start calling any member blindly without worrying whether the member exists or not.

The other situation where you have no choice other than an interface is where you want to implement 2 of them. You can inherit from only one base class, but you can implement as many interfaces as you want.

These are just few of the benefits. However, I would suggest you read some good article to get a better grasp of the topic.

It's not true that declaring the members separately in each class would be just as good because then they would be different members. For example, you can use a For Each loop to loop over any object that implements the IEnumerable interface. When you do this:

vb.net Code:

For Each item In collection

the compiler simply has to check whether 'collection' implements the IEnumerable interface or not. If it does then it knows that the member sit needs to be able to loop are present without checking to see that there are members with the correct names, correct types, correct parameters, etc., etc.

Another common example of where interfaces are used is when data-binding. When you bind data to a DataGridView, ComboBox or the like you must supply an object that implements either the IList or IListSource interface. That's because data-binding requires various members to be present in order to work. If your data source doesn't implement one of those interfaces then there's no guarantee that those members will be present.

jmcilhinney and Pradeep1210:

Thanks for the reply.

I'm not sure that I follow. What you guys explain to me about interface is very much different then that I read in MSDN. Is this the real capabilities of Interfaces?
Especially jmcilhinney's reply. Sorry, bro. I don't understand what you're saying at all. :o:o
Could you slow down a bit, maybe you can give some simple code?

jmcilhinney :
the compiler simply has to check whether 'collection' implements the IEnumerable interface or not. If it does then it knows that the member sit needs to be able to loop are present without checking to see that there are members with the correct names, correct types, correct parameters, etc., etc.

Could you please explain this subject more ?
Thanks

The term "interface" was not made up for programming. Think about your computer and the things you connect to it. How many of them have a USB interface? There were some people who sat down at a tabel and wrote out a definition of what the USB interface is. It was then possible for printers, memory keys, external hard drives, etc., etc. to implement the USB interface. Your computer knows exactly what the USB interface is. You can connect any one of the many thousands or even millions of USB devices to your computer and it will work because the computer knows exactly how to communicate to a USB device, i.e. a device that implements the USB interface. Now, how do you suppose we'd go if there was no USB interface defined and each device just did whatever it wanted?

Programming interfaces are the same. The interface defines a set of functionality that any object can promise to implement. If I write a method that takes an IList object, i.e. an object that implements the IList interface, then I know that any object that gets passed to that method will provide all the functionality defined by the IList interface. I don't care what that object is, how it implements that set of functionality or what other functionality it might have. I know it has all the members of an IList and I can work with it in those terms, i.e. I can loop through its items, get an item count, get or set an individual item, etc. You could pass an array, a List, a BindingSource or any one of a myriad other objects to that method and they would all work because they are implement the IList interface.

I'm enlightened a bit. Lets say I make an interface MyInterface of my own (it has sub Testing()), then I have 3 different classes ClassA,ClassB and ClassC implementing this interface. I assume that the code I write in sub Testing() for every class can be different and the application will work just fine, right?
In your years of experience in VB.Net 2008, do you ever need to make an interface of your own (meaning you can't use the interface provided by .Net)? If so, is it quite often or rarely? Could you show some code that employs the in-built interfaces already provided by .Net? I'd like to see the usage of these interfaces in real-life programming cases. Thanks

For a long time I rarely used my own interfaces at all. More recently though, my code is riddled with interfaces, mainly to improve the testability of the code. The interfaces don't really and anything to the functionality of the application but the make it much more testable.

I've already provided two everyday examples of using common interfaces: IList in data-binding and IEnumerable with For Each loops. If you want to see another one then check out the documentation for the ListView.ListViewItemSorter property.

Quote:

---

I'm enlightened a bit. Lets say I make an interface MyInterface of my own (it has sub Testing()), then I have 3 different classes ClassA,ClassB and ClassC implementing this interface. I assume that the code I write in sub Testing() for every class can be different and the application will work just fine, right?

---

That's correct.

Quote:

---

The interfaces don't really and anything to the functionality of the application but the make it much more testable

---

How does it make your code more testable?

I work with a different example of this every day. There are interfaces for such things as dataadapters, connections, and commands. The interface enforces the contract that certain methods will be implemented, and any object can be cast into an instance of it's interface. In other words, if you have a SQLConnection object that implements IConnection, and an OLEDBConnection object that ALSO implements IConnection, then you can have a method GetConnection that returns an IConnection object, and it no longer matters whether you have connected to a SQLServer database using a SQLConnection, or an Access database using an OLEDBConnection.

In my case, the code is generated. Either the program is generated to work with an Access database, or a SQL Server database, or some of both. The connection strings are different, but the connection returns an IConnection object, and the program works entirely with that. The only part that actually cares whether I am using the OLEDb namespace or the SQL Server namespace is a single method buried down deep in the basement. After that it's all interfaces that are common to either the OLEDb or SQL Server namespace.

Quote:

---

Originally Posted by KXTG2431

How does it make your code more testable?

---

If I have an interface IDataAccess that defines all my data access functionality then I can have my business logic layer work with just the IDataAccess interface. In my real application I would create an instance of the DataAccess, which implements the IDataAccess interface and provides concrete implementations of each member.

While I'm testing though, I create a FakeDataAccess class that also implements the IDataAccess interface. Rather than actually retrieving and saving data to the database, this FakeDataAccess class simply returns canned responses. For instance, instead of getting all the records from a table it might just make up some data and return that. Instead of actually saving a record to the database it might just return True as though a record was saved.

I can then test my business logic layer using this FakeDataAccess class and not have to depend on the functionality of my real DataAccess class. This makes testing faster, because I don't have to access the database, and it also means that I know that if a test fails then it was because of an issue in the business logic layer, not the data access layer.