Related to interface.

[padmaratna kamble]

Why we need interface?
If we can declare and define the same methods in our class also.

[Campbell Ritchie]

Some people look on interfaces as the ultimate example of the abstract class. An abstract class has some abstract methods and some not abstract. An interface has them all abstract.

The real reason you use interfaces is that you use interfaces. It would be conceivable to have a language without interfaces, but that is not the way Java was designed. Java is designed with single inheritance, so if you want any more methods you may have to use an interface.

You can call an object an instance of its class, or its superclass, or any of the interfaces it implements.

There are several methods in Java which expect an interface on what they handle. For example the sort() method in the Arrays class expects the Objects it sorts to express the Comparable interface. So your sort method looks for a Comparable object to sort. Comparable means it has to implement the method compareTo(), which returns a negative or positive or zero int, depending on certain rules which are in the API description of Comparable. [It is actually Comparable<T>, but we'll forget the generics for the time being.]

So, what do you do with an interface?
You,

implement a certain number of methods, and

use the name of the interface as a handle so methods can receive it as an argument.

Another example: There are several Listener interfaces in the java.awt.event package.
Whenever you do anything to a GUI application, eg move the mouse, push a key, push enter, click a button, an Event object is sent (see the Event types and EventObject), which looks for a Listener. That means you have to have a class which implements the SomethingListener interface.
When the Event object finds a Listener object (ie an object instantiated from a class which implements the WhateverListener interface), it acts as a call to the Listener's somethingHappened() method.
So you need the interface to have the method with the correct signature, and it has to have the name of the interface which the Event looks for.

Yes, the language could have been designed without, but it wasn't. And I think I have probably confused more than helped.

CR
[ April 26, 2006: Message edited by: Campbell Ritchie ]

[Jass Singh]

Originally posted by sachin kamble:
Why we need interface?
If we can declare and define the same methods in our class also.

One reason for Interface being there is to support multiple inheritance.

Otherwise why Interface is preffered over Abstract Class, you might get an idea from following:

Interface is a contract and it can be implemented by different people using different logic. Best example is JDBC ResultSet (or Connection, Statement etc) interface. Sun has made it an interface, indicating which all methods need to be implemented by DB Driver vendors. Since SUN doesn't know if driver will be for oracle or DB2 or MS-Access so SUN can't provide implementaion for any method. Now differnt DB driver vendors implement ResultSet according to their logic/requirement and underlying DB.

On the other hand if there was a situation that functionality of some method can be shared by all drivers then SUN would have made ResultSet an abstract class and provided implementation for that method.

In fact this a question I ask in all interviews: Is ResultSet an Inteface or Class ? And If yes then who provides the implmentation for it.

Regards,
Jass
[ April 27, 2006: Message edited by: Jass Singh ]

[Jody Brown]

I found this interview between Bill Venners (founder of Artima.com) and Erich Gamma (one of the "Gang of four" - design guru and one of the developers of the Eclipse platform) to be fairly enlightening on the subject and offers real world examples of how and when interfaces should be applied.

http://www.artima.com/lejava/articles/designprinciples.html

[Campbell Ritchie]

I think we are slipping off subject slightly.

I may be mistaken, but I interpret "program to the interface" to mean that we have a class which presents a face to the world. That face is its interface with the other classes in any applications. It means that you show a set of method calls, and each method call takes any number (including 0) of arguments and does any number of things and returns something.

Encapsulation means that we tell the world (in the API or our own javadoc) what the class does, but NOT how it does it.

The interface means that anybody using this class can expect that making a method call will produce a result; the programmer's job is to make sure that the same method call will always produce the same result. That is how we get reusable code in the first place. Once we have got the code consistent and reusable, anyboyd we give the code to can use it, and get the same result.

********************************************************************************

The thing called an interface in Java (there are similar things in other languages, including C#) is a means of making sure that when a method call is made to something, that it has a name for the class and a name for the method to get its hands onto.
Example (same as before). When you invoke the addActionListener() method of a swing component (eg a JButton), it takes an argument of type java.awt.event.ActionListener. So you have to pass an ActionListener. ActionListener is an interface, but if you write

class SomethingOrOtherListener implements ActionListener
{
   ...
}    

or

new ActionListener
{
   ...
}    

and fill in its method, it becomes something like a class, which can be instantiated into an object.

Now you have something with the correct class name (ActionListener) and a method of the correct name (actionPerformed) for the methods in the JButton to deal with.

Names: Imaging you have something like

public class MotionFrame extends JFrame implements MouseListener
{
   ...
   public void mouseMoved(MouseMotionEvent e)
      {
         ...
      }
   public void mouseDragged(MouseMotionEvent e)
      {
         ...
      }
}    

You can call it at least three things. You can call it a JFrame, a MotionFrame, and a MouseMotionListener. When your mouse moves across it, the mouse invokes the mouseMoved and mouseDragged methods. You can write whatever you think fit in those methods, but the interface forces you to implement methods with exactly the right name for the mouse motion to invoke.

I hope that has made it clearer. I agree with what Jass Singh says about inheritance; it is a way to make a class appear to "inherit" from several different classes.

CR

[Jeff Albertson]

Originally posted by Campbell Ritchie:
public class MotionFrame extends JFrame implements MouseListener

As an aside, usually when I see a GUI class defined in this way, it's an error in design. Why? Usually, it's an implementation detail that the frame is listening to the mouse, so this shouldn't be made public by being part of the implements part of the class definition. Better to have another class implement MouseListener -- perhaps an inner class that ends up extending MouseAdapter.

[Stan James]

In fact this a question I ask in all interviews: Is ResultSet an Inteface or Class ? And If yes then who provides the implmentation for it.

Interesting question. Another follow up question - why would I care? I've used it for years without giving it a thought.

JDBC is a neat example of inversion in layering. It has interfaces that applications may use and interfaces that database vendors must implement. All dependencies flow into JDBC and all the really interesting bits are just interfaces.
[ April 28, 2006: Message edited by: Stan James ]