why interfaces?

[Alpha Mak]

Heard a lot about java ranch,nice job
> you people are doing for java addicts.
> I've a Q,hope you can help me out.
> My question is
> about interfaces.Why sould we implement
> interfaces,and where.Since they have no non-abstract
> methods we do make thier adapters and use where
> needed then why interfaces and secondly how can I
> know thier level in heirarchy(I mostly get lost
> trying to remember them when I'm in API's).
> Hope you can help.
>
> Alpha Junior.

[Valentin Crettaz]

Hi Alpha Junior,
Why use interfaces ? Unlike C++, Java does not support multiple inheritance. Interfaces provide an elegant way to get around this lack of multiple inheritance. If you use an adapter then you cannot extend another class and thus you cannot take advantage of the real purpose of inheritance. By using (i.e. implementing) interfaces you can design your programs like if you were using multiple inheritance, because you are allowed to implement as many interfaces as you like. Interfaces are also a means of describing the blueprint of a given class by simply specifying which behavior the class should implement...
Concerning your second question, I think the hierarchy begins to stuck in mind if you practice a lot. You can also learn it by heart but the purpose is to understand how the hierarchy is organized and why it is not organized differently...
Hope that helps
Val

[Bindesh Vijayan]

Good Answer Val.I want to add something that with interfaces in use and multiple inheritance not allowed (as in c++),you can now have your class only one implementation.And the heirarchy get could be simply traced out.
Easing programmers job.
THANKS
[This message has been edited by Bindesh Vijayan (edited September 05, 2001).]

[FullMoonParty]

I'm glad someone else is having troubles with interfaces. I don't feel so bad now. There is NO other concept in Java that confuses me and frustrates me more than interfaces. I have read a number of articles and chapters in books on interfaces, and I am starting to believe I am just plain dense. I read them over and over and over and over and it still does not make sense.
Yet...I can articulate some (now) memorized facts regarding interfaces (ie. they are used to get around lack of support for multiple inheritance, they are similar to abstract classes except they provide no implementation at all, etc.)
I have not been able to find an example to make it stick. Right now the concept is very abstract (no pun intended). Most discussions on interfaces talk about the syntax. I got that part. I can define them. I can also implement them. What I can't do is tell a novice (my sister?) *why* I am going to use an interface (please do not say because I need multiple inheritance).
You guys have no idea how frustrating this is (or maybe you do). It's like dividing by zero--it doesn't compute. (for integers anyway). :-)
Let me *try* to describe why it eludes me...
An interface doesn't DO anything. (some of you may say that's the whole point). My rebelious mind says, why should I "implement" you when you dont DO anything for me? At least with an abstract class, I get SOME common functionality that is of use to me. All I get with an interface is a requirement that I implement some methods. I don't need an interface to tell me that I should implement some methods--I can do that on my own.
(I am not trying to be sarcastic or cynical--this is what my mind is thinking)
The example I always fall back on when thinking in OO is my college example years ago of an ATM application. This makes it easy to conceptualize abstract classes. Among other things, we had an abstract Account class with subclasses for Checking, Savings and CD. This is very tangible and real--we deal with this everyday in real life.
I then try to think, 'how would I put an interface to use in this context?'
It eludes me.
I keep reading and keep pursuing interfaces in the hopes that one day it 'clicks' and then it all makes sense. I'm planning on SCJP2 certification and I may get some/all questions on interfaces correct, because I understand (memorized?) the syntax/mechanics of declaring and using interfaces. But I don't know how to *design* using them.
Can anyone tell me how I might be able to use an interface in the ATM application example mentioned above? I desperately need to get past this mental block.
Alternatively, I used to program in VB--maybe an analogy to some concept there makes sense? I'm thinking they might be similar to the "handlers" that are available on UI widgets (ie. 'onClick, onChange, onExit'). The only problem is that these handlers exist whether or not use use them. If you decide to use them, you just pop some code in there. An interface on the other hand would require code in each of these (though a method definition and empty {} would suffice. Maybe this *is* an interface (in concept) and all the methods are predefined and a UI is available in VB to let the programmer stick in his/her code?
As you can see, I'm stretching for any analogy to make this concept click.
:-(

[james hoskins]

Hello FullMoonParty,
You may find you contravene the naming conventions on this sight - check them out in FAQ's.
Thinking about your problem with interfaces, why not consider the core Collections heirarchy which is entirely made up of interfaces and ask yourself why this is the case.
You mentioned the fact that interfaces give an outline for implementing a particular abstraction and that you didn't see the point of this as you were perfectly capable of thinking up your own abstract class to do the job. Now, lets leave aside the whole thing about multiple inheritance and concentrate on this idea. If you design your own abstract class to, say, outline the behaviour of a collection and go on to build a program around it then that will be fine for you, but what if you work with another programmer who is unfamiliar with your abstract class and the method names within it - she will have to learn your abstract class Collections and all the method names within and then go on to learn all the other classes that you have designed to implement basic behaviours which hardly promoted the idea of software reusability.
Think about the same scenario using the standard core interfaces of Collection. Your fellow programmer can come along and she doesn't need to learn your new methods or design to write usable code. If you have a class in your program that implements Collection then she knows she can create an object of that class and safely call add() or isEmpty() and that your class will provide those corresponding services. This seems to be the heart of it: interfaces form a contract ensuring certain services are provided and also act as markers indicating that those services are available in a particular class e.g. the Cloneable interface.
Hope that explains it.
Kind regards,
james

[Michael Morett]

Hi James,
You are right. I signed up without even noticing the LARGE notice about usernames. LOL.
Hopefully the post stays up. I will look into the Collections framework. This is a good point that I never considered.
Thanks.

[Michael Morett]

I spoke too soon James. It dawned on me that I recently worked with Hashmaps on a project and I just took a quick peek at the API.
Maybe I am getting away from your point (or totally confused), but I instantiated Hashmaps. And I used methods to put and get stuff from them. In other words, the Hashmaps had methods that provided immediate value to me. I wasn't starting from a blank slate.
I realize I digress, but you mentioned the Collections framework, and while I acknowledge that Hashmap implements Map, I fail to see the significance or utility of doing so.
What's killing me is that Map (or List, or Set), are interfaces. They don't do anything. So when I read that a Set is "a collection that contains no duplicate elements", I wonder how exactly is that enforced--there's no code in the interface definition for Set.
I think I am getting to the heart of my confusion in a roundabout way. A class *does* stuff. An interface doesn't. So I fail to see how List is different from Set, other than the methods they prescribe--yet the contents of these methods are determined by me, if I implement the interfaces.
The API descriptions of interfaces read as though they do certain things, yet by definition, they do not deal with implementation, but delegate that to the implementing class.
(I give up!)
:-)

[Jose Botella]

Bruce Eckel wrote in Thinking in Java :
Keep in mind that the core reason for interfaces is shown in the above example: to be able to upcast to more than one base type. However, a second reason for using interfaces is the same as using an abstract base class: to prevent the client programmer from making an object of this class and to establish that it is only an interface. This brings up a question: Should you use an interface or an abstract class? An interface gives you the benefits of an abstract class and the benefits of an interface, so if it?s possible to create your base class without any method definitions or member variables you should always prefer interfaces to abstract classes. In fact, if you know something is going to be a base class, your first choice should be to make it an interface, and only if you?re forced to have method definitions or member variables should you change to an abstract class.
Here you can read this excellent book http://codeguru.earthweb.com/java/tij/tij0080.shtml#Heading217

[marilyn murphy]

Check out java.sql Interface Connection:
DriverManager.getConnection( "jdbc:mysql://urlToDatabase" );
returns a Connection object which can be any object that implements the interface Connection. We don't know which Connection object is returned by the vendor's implementation of this method. We don't need to know in order to use it. Each vendor creates their own implementation using the methods defined in the Connection interface. So all you need to do is fill in the String which is given to you by the vendor and the method works. If you change from mysql to MS SQL server, all you need to do is change the string and the method still works fine, even though the implementation of the methods defined by Connection by the new vendor may be (and probably are) completely different. Polymorphism at its best.

[Ashfaq Ashraf]

Thank you guys big time cause it realy did help a lot
(I love this site)

Originally posted by marilyn murphy:
Check out java.sql Interface Connection:
DriverManager.getConnection( "jdbc:mysql://urlToDatabase" );
returns a Connection object which can be any object that implements the interface Connection. We don't know which Connection object is returned by the vendor's implementation of this method. We don't [b]need to know in order to use it. Each vendor creates their own implementation using the methods defined in the Connection interface. So all you need to do is fill in the String which is given to you by the vendor and the method works. If you change from mysql to MS SQL server, all you need to do is change the string and the method still works fine, even though the implementation of the methods defined by Connection by the new vendor may be (and probably are) completely different. Polymorphism at its best.
[/B]