Have you even bother searching your answer on Google first?
Maybe this liks can help you:
Click Here
Click Here
An interface is a "pure" abstract class. It provides only a form, such as the method names, argument lists and the return types, but not the actual implementation, not the method bodies.
Interfaces can contain fields, but they are implicitly static and final (constants).
As a quick example, take the Strategy design pattern. Say you have two vectors to be sorted, using two different methods. You'll than need to write an interface for a class that sorts a vector (array), and than implement that interface with two different sorting algorithms:
++
 <<SortVec>> 
++
+sortV() 
++


____________________________
 
 
 
++ ++
 MergeSort   QuickSort 
++ ++
+sortV()  +sortV() 
++ ++
well, the generation of the late seventies were wrong. they claimed 'Grease' was the word. when talking about interfaces, there are two words, but 'Grease' is neither of them.
the first one being 'Contract': an interface is a fixed contract which applies to any class that implements said interface. every such class must provide an implementation of each abstract method in the interface. either the class implements it itself, or it inherits an implementation of a super class, that doesn't matter.
the second one being 'Polymorphism'. interfaces can help you to simulate multiple inheritance in Java (do notice, I said SIMULATE multiple inheritance, since you don't inherit from interfaces). Multiple inheritance itself is not supported in Java.
just look at this simple concept:
you are supposed to write a method that prints the result of a mathematical equation. it takes the mathematical equation as a parameter. now, your goal is to have this for Sum, Subtract, Division and Multiply. let's say for your purposes, you have Sum and Subtract extend AddNumber, and Division and Multiply extend MultiNumber...
so, you would have to write (at least) two methods for this. using an interface will allow you to put it all in one.
public interface Equation{
public int getResult(int number1, int number2);
}
that's as simple as your interface needs to be. now, let's create your classes:
public Sum extends AddNumber implement Equation{
@Override
public int getResult(int number1, int number2){
int returnValue = number1 + number2;
// Add business logic if need be
// your class MUST implement this method, since it implements the interface
return returnValue;
}
}
public Subtract extends AddNumber implement Equation{
@Override
public int getResult(int number1, int number2){
int returnValue = number1  number2;
// Add business logic if need be
// your class MUST implement this method, since it implements the interface
return returnValue;
}
}
public Division extends MultiNumber implement Equation{
@Override
public int getResult(int number1, int number2){
int returnValue = number1 / number2;
// Add business logic if need be
// your class MUST implement this method, since it implements the interface
return returnValue;
}
}
public Multiply extends MultiNumber implement Equation{
@Override
public int getResult(int number1, int number2){
int returnValue = number1 * number2;
// Add business logic if need be
// your class MUST implement this method, since it implements the interface
return returnValue;
}
}
pretty easy so far, huh?
now, to have a running class:
public class Test{
public static void printResult(Equation eq){
System.out.println("The result = " + eq.getResult(1, 2));
// you know you can call the getResult for each object that is passed as parameter
// no matter who will later on add new classes that implement the Equation interface
// and try to pass it on, because, since they are bound to the contract, they MUST
// provide an implementation for: getResult(int number1, int number2);
// and thus, the compilation will never fail.
}
public static void main(String[] args){
Sum nS = new Sum();
Multiply nM = new Multiply();
Division nD = new Division();
printResult(nS);
printResult(nM);
printResult(nD);
// even though none of these objects are direct instances of Equation, you can still
// pass them as parameters to the method, because since they all implement the
// Equation interface, they will all pass a instanceof test for Equation
// => polymorphism
}
}
sure, for a decent application, you would've passed the integers (1 and 2 hardcoded in the above code) as parameters to the constructors, and added instance variables for them, but this is just meant as a simple example to show the concept.