PDA

Click to See Complete Forum and Search --> : Interfaces..What is the point?


|2eM!x
Feb 22nd, 2007, 09:44 PM
We are learning about interfaces in class, I really dont understand the point. It seems to me to be a complex way to keep a return the same value..Why not just make it return the right value instead of using this interface nonsense..? Is there something I am missing or a good explanation here?

CornedBee
Feb 23rd, 2007, 01:58 PM
Interfaces have very little to do with return values.

The point of interfaces is that you can treat various objects the same way, regardless of their actual type, if they fulfill a given contract. It's basically the object saying, "Look, I can do this." and you not caring about anything else beyond that. Interfaces are important for decoupled code (Good Thing) and extensibility (another Good Thing).

Take for example this application I have. I recently switched the backend data storage from a simple relational database to an implementation of the Java Content Repository specification. Interfaces play two big parts here:
1a) Because all other components of my application only use interfaces to communicate with the data storage, I could simply write a new implementation of the interface and plug it in - the other components didn't need to be modified.
1b) You could argue that I could have used classes and just changed their implementation. True. But the way it is, I can use two different implementations at the same time, without having to reconfigure and recompile. The second implementation is a purely in-memory implementation that I use to test the other components.
2) Because JCR is specified in terms of interfaces, I only need the API and can compile my code. I can then plug any implementation into the program without having to recompile, whether it's Apache Jackrabbit or a commerical implementation.

Check out how interfaces like Comparable or Comparator are used in the Java standard library.

TBeck
Feb 23rd, 2007, 10:40 PM
Interfaces are also useful when you create a class that you want to share with someone else, but don't want to share the code. The other person will beable to use the class via the interface but not beable to see the code of the class itself.

lunchboxtheman
Mar 1st, 2007, 11:47 AM
You can also pass objects based on what interface(s) they implement. This allows a method to take in objects that implement a certain interface, regardless of their type.
For instance, Strings implement the interface Comparable. Say you've also coded a Car class that implements the comparable interface. You could have a method somewhere who's formal parameters could include:
methodName(Comparable obj){}
This would allow the methodName to accept ANY object that implements the Comparable interface, regardless of the incomming object's type. You could send either a String or a Car to this method with no problems.

It's sort of a hard concept to understand, and an even harder one to explain. So if anyone can expand on that conecpt further or clarify it, feel free.

|2eM!x
Mar 3rd, 2007, 10:16 AM
You can also pass objects based on what interface(s) they implement. This allows a method to take in objects that implement a certain interface, regardless of their type.
For instance, Strings implement the interface Comparable. Say you've also coded a Car class that implements the comparable interface. You could have a method somewhere who's formal parameters could include:
methodName(Comparable obj){}
This would allow the methodName to accept ANY object that implements the Comparable interface, regardless of the incomming object's type. You could send either a String or a Car to this method with no problems.

It's sort of a hard concept to understand, and an even harder one to explain. So if anyone can expand on that conecpt further or clarify it, feel free.

Well your response made the most sense to me, so thankyou. However what is the point then? You can pass a car or a string that both implement comparable -- but why would you want to compare a car and a string?

edit**
thanks to everyone, I just re-read my post and I sound like an ass. Thanks for the info guys, but his just made the most sense to me:wave:

penagate
Mar 3rd, 2007, 10:13 PM
Inheritance says what a class is; interfaces say what a class can do.

As CornedBee says, it's a contract: if the interface spec is locked down, both the class author and code author can start writing their code without having either part complete yet.