Prejith,

   Try to imagine a computer's keyboard which contains the logic that
executes when a key pressed.
   In this scenario, we need separate keyboards for each processors
ie, A key board which uses in Pentium processor can't be use with AMD
processors.
  To solve this problem we need to extract the processing logic from
Keyboard and let it done in processor.
  Then there is a problem arouse that the processor vendor may will
develop different implementation and functions for keyboards for their
processor. So we need to give a commor rule for developing keyboad
logics for the processor vendors in the following way:

public interface KeyBoard  {
         void a();
         void b();
         ......
         ......

}

public class AMDProcessor implements KeyBoard {
         public void a() {
               .........
         }

          ..............
}

public class PentiumProcessor implements KeyBoard {
         public void a() {
               .........
         }

          ..............
}

Interfaces are not another way to implement multiple inheritance.

I think this explanation may help u to understand interfaces.

Francis

Hi Prejith,

First of all, I personally don't like the explanation that 'interfaces
are a workaround for multiple inheritance'. There is NO multiple
inheritance in Java, live with it ;)
The point is that an interface is not (exactly) the same concept as
inheritance (hence the two different keywords used: extends and
implements).

The point of having 'empty methods' is real object orientation:
whenever you write a class and give it methods, all the other classes
calling this method shouldn't care about the actual code. Instead it
should know only know three things:
1. the method's name
2. what arguments to pass
3. what to expect (the return type)
And that is exactly what an interface provides.

Rgds,
Ben

Because an interface is kind of like a contract about the contents of
the implementing classes. That is, the classes implementing a particular
interface can be relied on to have at least the methods defined in the
interface. For example, all ActionListeners have the
ActionPerformed(ActionEvent e) method, which makes it possible to handle
them all in the same way by invoking the said method. What the
ActionListener is supposed to actually do when the method is invoked is
left for the programmer to decide.

It is not a workaround,
the way Java implements inheritance / interfaces
has the side effect of
eliminating the classic multiple-inheritance issue.

An interface is a promise to implement a method with a specific name and
 a specific signature.

The beauty when it comes to the classic multiple-inheritance issue is;
two different interfaces used for different purposes
could potentially have a name/signature conflict,
in which case sorting out the mess
is left as an exercise for the person implementing the class.

As Java only allows you to extend one class
there can never be two conflicting implementations.

Incase the other replies dont clear the issue up for you, let me give
you my favourite example...

Let's say you are writing a little GUI widget for selecting a date from
a visual calander. The user can use the wiget to scroll to a month and
click on a date.

What you might do is create an interface, called 'Dateable' that looks
like this...

public interface Dateable
{
   void setDate(Date date);
}

and your widget code would look like this...

public class CalanderWidget
{
   private Dateable dateable;

   public CalanderWidget(Dateable dateable)
   {
       this.dateable = dateable;
       //some other stuff, setting up widget etc
   }

   //This is called when the user selects a date from the panel
   //Calling code is not shown
   private void dateSelected(Date date)
   {
       dateable.setDate(date);
   }
}

What you are saying is... "My CalanderWidget can provide a date to an
object". You dont care at all what kind of thing you are scheduling. You
could have classes like this...

public class Meeting implements Dateable
{
   public void setDate(Date date)
   {
      //some code
   }
}

or

public class NuclearLauch implements Dateable
{
   public void setDate(Date date)
   {
      //some code
   }
}

What you have done is decouple the widget from the object that is
supplying. The widget will accept any object that implements Dateable
and it knows that the setDate method will be available to use. What it
does not know (or need to know) is what other stuff is going on in the
'Dateable' class. Your widget can be used for scheduling meetings or
setting up nuclear lauches with equal ease and without changing the widget.

If you do end up scheduling a nuclear lauch though... I, for one, would
appreicate a heads up :)