I think it usually comes down to three reasons... (1) A class can only extend a single class, whereas it can implement multiple interfaces (Interfaces are Java's version of multiple inheritance in C). So, as soon as you get to the point where extending a single class just isn't sufficient, it's no longer really a choice... well, I suppose you could push all the functionality up the inheritance tree, but that gets ugly in a hurry.
Since you can only extend a single class, you want to do so carefully, kind of like if your in a desert, you don't want to drink your last glass of water lightly :) So, if you keep implementing interfaces instead, you keep that one inheritance path open to you. It's really *not* the same as multiple inheritance because you aren't inheriting functionality, but it in a sense leads to the same thing because you of course have to implement all the methods of the interface, and presumably you do so in a meaningful way, so in the end you get the same basic effect. (2) It allows for polymorphism. If a given class implements a given interface, you can treat the class as an instance of the interface. So, if you have a Dog class and a Dolphin class and a Lizard class and they all implement the IHasBabies interface which has a single giveBirth() method, obviously the method by which each of the classes "gives birth" is quite different, but all you need to do in your code is: ((IHasBabies)animal).giveBirth(); ...and animal can then be an instance of a Dog, Dolphin or Lizard and the above code doesn't have to change at all. Note that if there was true multiple inheritance you'd be able to do the same thing. You may be asking "well, why not just have Dog, Dolphin and Lizard extent a HasBabies class"? Again, it comes back to the multiple inheritance problem... what if you want to have a class Eats and a class Sleeps and a class Runs, etc., to encapsulate the common functionality? You either have to put all that stuff into the one class that Dog, Dolphin and Lizard extends, which is ugly, or you get into a situation where there is no guarantee about the interface each class has... maybe Dog has sleepLong() and Lizard has sleepShort(). Implementing an interface that describes sleeping, then one that describes eating, etc., guarantees that each of the implementing classes exposes the same generic functionality, even if the specific details are different for each. (3) Following on the heels of the last paragraph, implementing an interface is a clean way of saying "ok, this class is guaranteed to have the following members". It's a matter of extensibility... imagine when you have to add another type of animal to the above example... maybe you want to add an AlienFaceHugger class, which has yet another method of giving birth (eeewwww!)... if it implements that IHasBabies interface, then you know it is guaranteed to have that giveBirth() method, even if you don't know what goes on inside it, and most importantly, this will be enforced at compile-time. So, it isn't so much a choice to use interfaces vs. not using them... there are certain things that you won't be able to do without them in Java. Or, at least there are things that you won't be able to do WELL in Java. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, August 10, 2005 10:47 am, Carl Smith said: > > In Java/J2EE community, it seems that a lot of experienced developers tend > to use a lot of interfaces, however, a lot of junior developers ignore > using interface. I am not sure why interfaces seem to be favorite to some > experienced developers. Can some one explain this?Can you give examples > where an interface is preferred? > > Thanks. > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
