Interfaces allow you a method of advertising that your class meets the conditions of being a certain "type" - along with the knowledge that any methods (or variables) relating to that type can be used. This allows the compiler and JVM to know that your class can "fit" into any variables that are declared with any "type" that your class implements. This also gives you a means of being more than one "type" at the same time, by implementing multiple interfaces.
"JavaRanch, where the deer and the Certified play" - David O'Meara
A class has two faces: its public interface and its private implementation. Please note I'm using the word interface in a more general sense than the keyword interface in Java. An interface of a class is a publicly accessible description of its behavior, i.e. its methods. You can try to imagine that this interface is some sort of "contract" between the client and the class. The class guarantees that if a client invokes method XXX it will behave as specified in the public interface, no more, no less. For example, in your 1.4 docs, in your Math class, there is method called max(int, int). It promises to return the smaller of the two parameter values, every time. It doesn't say how, though, and you're not supposed to know. As long as the method does what it promises, however, the class is fulfillling its part of the contract, and a client couldn't ask for more. How a class fulfills its contract is called its implementation. There are many ways of implementing the same method, and they all differ in performance, speed, accuracy, etc. Of course, any programmer worth his salt will eventually have to consider ways of optimizing code performance. It could be the way his application is designed, or the way his classes are implemented. Better technologies, new APIs are basically screaming to be included in "sprucing up" an old implementation of a method. So the public interface remains the same, the same old methods, but inside the implementation could be cutting-edge. Given all these changes, will the client have to modify any of his code? If the public interface did not change, then the client need not stir a finger. If you used classes, modified and improved implementations would show up in the subclasses, since these classes must override previous implementations. The burden is now upon the client to keep track of the most recent incarnation and recode accordingly. There are still other considerations, like the fact that interfaces (as the Java keyword) allow Java to have multiple interface inheritance, but I think I'm getting long-winded as it is.... -anthony
Hi Geetanjali Your question is a common one I get from my students (Java as well as Visual Basic students). They understand how to create an Interface, but wonder why in the world they would ever need to do so. In the work environment, we typically have several types of programmers. If you're really good at what you do, eventually you get to write code for others to use. If you're very, very good, you may even write code that's incorporated into the JDK (but that's another story). In the Java world, this code takes the form of a class, containing methods. Sometimes it takes the form of an Interface, which you can think of as a class containing methods which have no code. Back to why? Let's pretend that you work for a company that wants all of its applications (applets, servlets) to perform some rudimentary security functions such as validating the user, maintaining an audit trail of actions performed against one of the many corporate databases, etc. This is fairly common in the corporate world. You, as the top notch programmer at this company, decide to write a class to implement methods such as LogIn, VerifyUser, RecordAdded, RecordUpdated. The problem is that the company's applications may run on a variety of platforms (Unix, Linux, Windows), and interact with a variety of databases (Oracle, SQLServer, Sybase, MySQL). Plus, there may be new platforms and Databases in the future that you can't even anticipate. Rather than write the code for each of these methods, you design an Interface called Security containing just the Method signatures, not the code, and your boss then forces every Java application written to implement this Interface, leaving the actual implementation of the methods up to the programmer (who at that time will know the implementation details). Does this help? John Smiley
<a href="http://www.johnsmiley.com" target="_blank" rel="nofollow">John Smiley</a><br />Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0072131896/ref=ase_electricporkchop" target="_blank" rel="nofollow">Learn to Program with Java</a>