An interface declares methods without specifying how they'll behave. Classes that implement the interface can use any implementation they like, but they MUST implement all the methods in the interface.
It's good to look at an example: java.util.List, the interface for all List data structures. It declares several methods (e.g., get, set, add, remove, indexOf, etc.) that any object that wants to be a List must implement. But it doesn't say anything about HOW to implement those methods. If you decide to have a list with an array of Objects as its underlying data structure, like java.util.ArrayList, you'd implement those methods differently than you would if you used a linked list, like java.util.LinkedList. Both are Lists, they just implement those methods differently. If you decide to write your own implementation of java.util.List you're free to do so. Just create a class that implements that interface and fill in all the methods as you please. When you're done you can use your class any place in Java where a java.util.List is used.
Actually, it is a straightforward concept, but it is not always easy to find a place to use it.
An interface describes an abstract class and method signatures that can then be implemented by concrete subclasses that extend the interface class. Hence, think of the interface as a specification of what you want to do and the subclasses as the implementation.
The real power here is that you can define an interface and then change the implementation classes without having to recompile the code that uses the interface. This is similar in concept to DLLs in windows. I can change the behavior of my code in windows by replacing a DLL and never have to recompile my main code module as long as I don't change the interface to the DLL. The same goes for the Java Interface. I can change the implementation classes and as long as I don't change the Interface class, I can redeploy a new subclass to repair defects or create new behavior.
The runtime type interface manager manages this for the developer.
It is pretty cool. Again, you have to find a paradigm that supports the need for this abstract behavior to make it useful. There is also additional runtime overhead associated with the use of abstract classes, so use them judiciously.
First of all you have to know the definition of an interface.
An interface can have operations and attributes.
The attributes must be FINAL and STATIC.
The operations are ABSTRACT, they have no body, but every class that "implements" that interface
could specify the behaviour of that operation (= a method).
Maybe you know something about Object Oriented Analyse and design.
You can create an interface to oblige some classes to implement some operations.
(protected variations, polymorfisme)
I will give an example:
the subclasses are Car and Airplane.
(You can choose to implement a superclass that calls Vehicle)
OR you can choose an interface. The interface will contain the abstract methods.
for example: stop(), start(), openDoors(), ...
Airplane and Car will implement those operations, they will have the same name, but the behaviour is quite different (= polymorphism).
You will make a game and every class uses the same attributes.
final static int GO = 1;
final static int PAUSE = 2;
final static int STOP = 3;
you can put those those attributes in an interface.
I read an interesting book about OOD
maybe you can read it too ?
Applying UML and Patterns (Craig Lairman/Prentice Hall)
nice answer but.....as you have give 4 differences .....i think 3rd one is not truely currect....as in both the cases afterall method of base class or method of interface is overridden without noticing anything in that method !! .....so that is only syntactic diff......i think.......any way ...but answer was to the point & describled very well