my dog learned polymorphism*
The moose likes Beginning Java and the fly likes interface example III (question) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "interface example III (question)" Watch "interface example III (question)" New topic
Author

interface example III (question)

barclay mcdaniel
Greenhorn

Joined: Apr 18, 2008
Posts: 11
if interface methods have no body, so to say, and interfaces only declare method(s) for implementing classes...

question/understanding/argument is...

with method overloading available, why not put the methods in the class(es) themselves and use no interface?
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 10905
    
  12

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

----OR----

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
barclay mcdaniel
Greenhorn

Joined: Apr 18, 2008
Posts: 11
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
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 10905
    
  12

ok... I work for Initech. you work for Globoworld. you want to access my database.

I say "no problem. here's how you do it. To get an object, you call the static method getDBTalker(). It will return something that implements the dbTalker interface."


so, you write your code:

dbTalker mydbTalker = getDBTalker();
mydbTalker.connect();
mydbTalker.insertData();

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.
barclay mcdaniel
Greenhorn

Joined: Apr 18, 2008
Posts: 11
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...

thanks
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 10905
    
  12

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: interface example III (question)
 
Similar Threads
interfaces!
Does run() method is declard i Thread?
are valueBound and valueUnbound method thread safe?
interface doubt
JLS 6.4.3 The Members of an Interface Type