well, the methods ARE in the classes, but I assume you mean why not ONLY have them there.
interfaces come in handy (I think) when you are working with large development projects, or even have different companies working together in some form or another.
let's say your code is going to ask my code for a 'widget' object - maybe it is the object that lets your code talk to my database, for example. We have two options...
1) I tell you it will be a class called 'databaseTalker'. you write THOUSANDS of lines of code, creating databaseTalker objects, calling its methods, doing all kinds of neat database talking stuff.
Then, in a year or two, I come up with a betterDatabaseTalker class. It's faster, smaller, sleeker... in every possible way, better. you want to use it. You have to re-factor every line of your code to use it, go through an exhaustive testing cycle, etc. hundreds (if not more) man hours are spent doing this
2) I tell you my class will IMPLEMENT the dbTalker interface. So, you write code to use dbTalker references. you don't REALLY know what the name of my class is, but you know you can 'pretend' like it's a dbTalker.
Now when i change and come up with my new class, it will ALSO implement the dbTalker interface. the underlying methods are completely different, but you don't care. you don't have to touch your code, because as far as you are concerned, both are dbTalkers.
which sounds better? [ April 21, 2008: Message edited by: fred rosenberger ]
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Joined: Apr 18, 2008
if interfaces only provide method names- where's the advantage? that is, if one would have to make the method bodys themselves anyway... how would they know what's allowed and/or not-allowed for the newer class(es)
i just don't see how it's needed w/ method overloading anyway- well, i guess it keeps you from having to type method "names" (method declarations) and that's it
You don't really know that the ACTUAL object you are getting is a talkToTheDatabse object. you just know what methods you can call.
That gives ME the freedom to change things as much as I want. I can sent you ANY object I want, as long as it implements the methods we agreed upon in that interface contract. Using an interface didn't really save me any work, but it does save you a lot of work if i decide to change something.
Joined: Apr 18, 2008
ah, i caught it there, and i remember reading it- the 'value' is in the method 'names', nothing else... and is this correct: with overloading being available, you could add what-ever parameters you would like, just leave the old methods in place... if that is correct, is this also: an interface can have multiple methods with the same name and only one of them needs to be 'useded' by the calling class (as this would meet the requirment of implementing/instantiating, what-ever-the-word-is, all methods in an interface, correct? (is that too wordy, or does my question make sense) and by the way: you are helping me a lot fred...
i would say it's not just in the method names, but also in the interface name. you can write you code as if the underlying object IS an object of the interface name. you can't REALLY create an object of type <inerface name>. but you can create the reference like you did.
this goes to a design pricicple: Code to an interface, not an implementation. if you write your code to use a SPECIFIC class/implementation, it's very hard to change your mind later.
many of the standard java collections implement interfaces. you write your code to use the Map interface. behind the scenes, you use a HashMap. Then, after a month or two, you decide that a TreeMap would serve your purposes better. you can change it and not worry about all your code where you did:
Map myMap = <however you get your 'Map' object>;
the code on the right can return a HashMap, a TreeMap, or some other, custom class you write, as long as it implements the Map interface.