Re: What's the use of an interface
Hakusa@gmail.com wrote:
I'm reading the http://java.sun.com/docs/books/tutorial/java/TOC.html
tutorial and I'm passed interfaces, but I can't figure out what's so
good about them. If I wanted to make all the methods, why don't I just
make them instead of implementing an interface that seems to add
nothing, but the necessary to make all the methods you would anyway?
Please rid me of my ignorance.
PS: I've also read about abstract classes for instead of interfaces,
but I think I'd rather make a static class with static methods.
For one thing, interfaces help get around the limitation (feature?) of
only allowing a class to extend 1 other class at a time. I mainly
consider that a feature although it can be annoying at times but I
usually find a way around it and I'm happy again.
Another thing is that when a class implements an interface the class
also becomes an instance of the interface type. So if you have an
interface called Date you could create a class called Gregorian that
implements Date you make Gregorian a Date class. So it works like
inheritance but you aren't limited to 1 interface like you are with real
inheritance.
Third, you are right in that an interface only defines method signatures
however there is a good reason for that. By using this feature in
conjunction with the last one I listed you can define the methods to do
work specific to the class that implemented the method.
For example: I have a program that has a JTabbedPane with 3 tabs. One
tab has a JList, the other 2 tabs each have a JTree on the left and a
JList on the right but they show different data. I created a class that
implements the Runnable interface to make it do work in a thread. The
results from the thread are then passed back to the tab that spawned the
thread. I wanted the thread class to be generic so it can be used
across any of the tabs but I wasn't sure how I could make sure the data
from a particular search was passed to the correct tab to be displayed.
I decided to make an interface that each of the classes that make up the
tabs would implement and pass the class that creates a tab's GUI as an
argument to the thread class. Since those 3 tab classes were considered
to be of type AsyncSearchInterface it was easy to define the thread
constructor to allow that. In the AsynSearchInterface interface I
specified a method called updateGUI() that would be called within the
AsyncSearch thread to give the tab its results. The individual tab
classes then define how they process the results. The usefulness of the
interface came in handy here because I could define in each of the tab
classes what I wanted each of them to do within updateGUI(). The first
tab needed to update its listModel but the other tabs had to update a
listModel (that wouldn't contain the same data as the other one) but
also a treeModel.
The interface method can do different things and the thread doesn't
care; that is the power of only declaring method signatures in the
interface without specifying their body definitions. This is even more
apparent if you have more than 1 class that can utilize the interface (I
had 3) otherwise you are correct, you could just define all the methods
in one of your classes. But if those methods need to be used elsewhere
but the work inside of them is different even though the classes have to
be treated the same then an interface will help immensely.
Those are the reasons I like interfaces. I'm sure there are more but
those are off the top of the head of a non-professional programmer (but
I develop for fun, yes, for fun).
Brandon