I know that an interface does not have a body just a method definition. But when should I use interfaces? If I provide someone a set of interfaces with no body, why would they feel a need to write the function body? Would they be better off writing their own abstract class with abstract methods in it.
Edited:
I guess the use of Interfaces is more when you are a part of a team. Suppose Team A writes a code for something and they wanted to see if a call to a method. with name getRecords(), is done or not. This will help Team B to write the body of the interface provided to them and Team B has to keep the method name similar so that code of Team A runs.
Just a thought. I might be wrong. I think Interfaces have no use for a single developer.
Edited:
Thanks all for the answers. With what you all have replied, I think Interfaces have more use when you are making something like API?
One reason to use interfaces is when a class will implement a number of interfaces. An abstract class cannot do that.
One example is a class which handles mouse movement and key presses will implement both the (ficticious) IMouseMove and IKeyPress interfaces.
Even as a single developer interfaces can be a very useful tool. Let me try to illustrate with an example.
Let's suppose you're developing a system to manage a library catalog and the library will lend both books and DVDs. You decide to create classes Book and Dvd to model items being lent but now you want to implement polymorphism so that you can deal with items rather than books or DVDs. The question is should Item be an abstract class or an Interface ?
In this instance you probably want to use an abstract class since there is functionality common to both Book and Dvd that you can provide by a parent class, for example checking out or returning an item.
Now let's say you want to implement a persistence mechanism for your library catalog. You've decided you want to store some data in a database, some data in XML files and some data in comma delimited files. So the question now is how can you go about doing this in a polymorphic way that allows you to deal with a general persistence API ?
In this case you should probably define an Interface that can be implemented by each of your classes providing the database, XML and comma delimited persistence since each of these persistence mechanisms provides similar features i.e. storing and retrieving data, but each will be implemented very differently. This will allow you to easily change which persistence mechanism you are using without having to make lots of changes to the code that uses the persistence mechanism.
To add to previous answers, interfaces help you during unit testing by allowing you to inject a mock object based on an interface into your code, allowing you to simulate specific scenarios and also to isolate your unit test to a specific component without relying on external components.
For example, suppose you have a business logic class that uses a data logic class to retrieve data from a data source and then process it. By creating an interface for the data logic class which it then inherits, you could create a mock/fake instance of that class based on the interface and inject that into the business logic class you're unit testing. The mocked instance can be defined so as to expect certain method/property calls, throw exceptions at certain points, return valid outputs etc etc. This means, your unit tests can run quicker/potentially more reliably as they are not reliant on the underlying data source being available/don't actually have to connect to it. And you're isolating the unit test down to a specific unit of code.
Java lang does not support multiple inheritance since interfaces are used to achieve the goal.
For a class to be abstract only 1 method has to be abstract ; Whereas in case of interface all methods are abstract .
At first glance, abstract classes and interfaces seem like a no-brainer. Why provide just an interface when you can also provide some base implementation? After investigation, you'll find that there is more to this.
That said, there are a number of reasons to use interfaces. You can find a decent blog post about the differences here.
That said, consider the fact that you can create an interface (a "contract" that says your class definitely supports certain calls/method signature invocations), but you can only provide a single abstract class. Also consider the fact that you can create an abstract class that also implements one or many interfaces, and inherit from this. This isn't a edge-case. This is actually done quite frequently in API's meant for high extensibility.
Check out the blog post I pointed you to and you should get a thorough understanding of when to use each and why you would use them. I would also highly recommend a good book such as "CLR via C#" by Microsoft Press. You'll learn a great deal!
The reason interfaces exist is due to the 2 principle concepts of OOP, which is "identity" and "functionality"
Classes have functionality and an identity. With inheritance, objects instantiated can have a lot of functionality and multiple identities.
Interfaces are an identity without functionality. The functionality will be provided by the class instantiated.
The third form, a "mixin" is functionality without identity. Programming languages like ruby provide this third form of inheritance.
How you use an interface differs by the context of your programming language and your circumstances, but just remember, interfaces are used to define identities which are enforced onto objects.