Hmm... i dont think so. As shekhar said IS-A holds for inheritance, similarly interface stands for behaviour . Two different objects communicate via an interface where as in an IS-A relationship an object actually inherits the properties of another.
A class implements interface is called as realization.. as per UML.
Hope you got me..
Joined: Jun 22, 2005
what exactly is it that we inherit from an interface anyways , a class extending an interface is only forced to provide a body to all the methods of the interface
Bhavesh! That is where the difference is, interfaces are always implemented never extended . When you say "implementing" then you just know you have to implement a behaviour, how? you are not aware of it, you may do whatever you want to implement it. When you say "extending", you already have some idea of what you are going to do, you may either want to follow it or change/modify if you want to.
Joined: Jan 17, 2005
Thanks everyone. So the relationship of a class with its interface cannot be called IS-A. Is there any other term for describing such a relationship ?
[Devi]: Can the relationship between a class and the interface implemented by it be called IS-A ?
[sekhar]; Interface dosen't consits of any state..to say.. IS-A relation..
An interface doesn't implement stateful behavior, but it certainly can reuire it of implementing classes. For example the Iterator interface requires implenting classes to remember which items in a collection have already been iterated over, and which have yet to be iterated over. Any Iterator must have state.
On the other hand, I'm not sure why this matters. State has nothing to do with the IS-A relationship. Where did this idea come from?
I suspect that the problem here is that many books talk about IS-A when they first describe the concept of inheritance, and this is usually before they talk about interfaces. Later when these books do describe interfaces, they don't talk much about IS-A since that's old news. But that doesn't mean that classes do not have an IS-A relationship with the interfaces that they implement. It just means that few people bother talking explicitly about the IS-A relationship after it's first introduced.
[bhavesh]: what exactly is it that we inherit from an interface anyways , a class extending an interface is only forced to provide a body to all the methods of the interface
Aside from inheriting any constants and static nested classes or interfaces defined within the interface, a class inherits the method declarations from an interface it implements. It also inherits the full API of the interface (meaning, the verbal description of the behavior of a class or interface), and is obligated to obey it. This is not enforced by the compiler, but is subject to human interpretation. If you implement an interface but your class does not behave according to the description given in the interface's API, then you have lied to the other programmers who read the APIs of the class and the interface it "implements", and they will consider your work to be incorrect.
[Akhil]: interfaces are always implemented never extended
False - an interface can extend another interface.
[sekhar]: So the relationship of a class with its interface cannot be called IS-A.
"Can the relationship between a class and the interface implemented by it be called IS-A ? Or is it only for pure inheritance?"
The "IS-A" relationship in essence means that anywhere a derived type may be used, a base type may be used. Now I know I am using the terms "derived" and "base", which are associated with Class inheritance, because I couldn't readily think of more generic terms that include interface inheritance.
Nonetheless, if you define the "IS-A" relationship to mean that anywhere type D may be used, type B may be used, then you have an "IS-A" relationship. Interface implementation then certainly creates an "IS-A" relationship. [ June 28, 2005: Message edited by: J Borderi ]
Joined: Jun 22, 2005
an interface can extend another interface.
Agreed Jim! I was waiting for it.
But friend, will "IS-A" relationship hold always. say if we have a class myFrame extends JFrame and implements ActionListener
I guess, an "IS-A" relationship will hold even when you track down the whole hierarchy of inheritance, but that may not be the case with interfaces... two VERY DIFFERENT classes may implement same interface, but may never have a relation in common. [ June 28, 2005: Message edited by: Akhil Trivedi ]
Joined: Oct 23, 2004
"say if we have a class myFrame extends JFrame and implements ActionListener so myFrame IS-A JFrame... makes sense. Also myFrame IS-AN ActionListener??? Not certainly, how about myFrame has behaviour of ActionListener"
Perhaps you will have a better understanding when you realize that, in your scenario, "everywhere you may use an ActionListener you may use a myFrame."
Why not? A MyFrame is an ActionListener. Sure. I don't really like this sort of design because it imposes too many unrelated responsibilities on a single class - I'd rather make a separate class nested within MyFrame which handles the actionlistening responsibilities. But that's a design decision. If you choose to have MyFrame implement ActionListener, then it is an ActionListener.
two VERY DIFFERENT classes may implement same interface, but may never have a relation in common.
But they do have something in common - whatever methods the interface defines. If they're very different, that's probably a sign of poor design. You can create similarly poor designs extending a useless base class if you like. That doesn't prove or disprove much about the IS-A relationship - it just means that if a class or interface is poorly designed, then it can difficult to make meaningful statements about it.
"has behaviour of" does not mean you can completely replace it. Let me put another example all (oops sorry some) electrical appliances, would implement pluggable interface but that doesn't mean you can replace a fridge with a water-heater. Ofcourse, fridge will have a behaviour of being pluggable and at same time water-heater as well.
Further, same above quote will also contradict with "IS-A" relationship, won't it?? Have a look at this...
"everywhere you may use an ActionListener you may use a myFrame, because myFrame IS-AN ActionListener"
Joined: Jun 22, 2005
two VERY DIFFERENT classes may implement same interface, but may never have a relation in common. "But they do have something in common - whatever methods the interface defines."
Absolutely right! But "will IS-A relationship hold?" is the question... ok, ok ok... let me not mess-up with myself. I would like to learn one thing from you guys, can you tell me if an "IS-A relationship" should bound to hold in the hierarchy,
A extends B -------> IS-A holds, also C extends B -------> IS-A holds.
now, should there be implicit "IS-A relationship" between A and C??? If it the answer is "yes", then I would stick on to deny, "interface = IS-A relationship"
[ June 29, 2005: Message edited by: Akhil Trivedi ] [ June 29, 2005: Message edited by: Akhil Trivedi ]
I guess, in your example you wanted to put like, B extends A, C extends B.
Rather than, A extends B, C extends B
because in the hierarchy you have put , C IS-NOT-A A because both are extending B but it doens't mean that C IS-A A. C can be adding more behavior and things. C and A will be siblings/peer in that case not parent/child relation.
e.g. 1. Car (equiv. to B class in your latest example) 2. V6 engine car (equiv. to A class in your latest example) 3. V12 engine car (equiv. to C class in your latest example)
Here, V6 and V12 both are Cars BUT V6 and V12 are not parent/child in any sense.
If it was like a chain, B extends A, C extends B then C would have "implicitly" been having IS-A relation with A.
The IS-A relationship has nothing to do with the mechanics of inheritence per se.
This assumes that the marketing literature and the subsequent texts portraying the doctrine hold true. Let's just make some assertions without any basis provided whatsoever, just like that literature does (after all, it has millions of followers): - The only legitimate form of inheritance is interface inheritance. - Concrete behaviour inheritance is an implicit software design flaw and requirement defect, assuming the requirements strve for maintainability, clarity, ease of use, and some other fundamentals that developers often implicitly strive for. - In the context of Java, and the fact that concrete inheritance is illegitimate, this also implies that non-final classes, and the protected keyword should never be used. Don't be fooled into thinking that it is the extends keyword that shouldn't be used as Allen Holub has done http://www.jtiger.org/articles/why-extends-is-not-evil.html - Given the only legitimate form of inheritance, the use of "is a" certainly describes inheritance - in fact, it would be silly to subtype an interface with another interface if those interfaces (aka contracts) don't have a "is a" relationship to its supertype contracts. [ July 03, 2005: Message edited by: Tony Morris ]
atleast the "instanceOf" example at pages 13 & 14 in Chapter 3 from K&B should scream the same point. You have a class that implements an interface, now the objects of class succeed to be "instances of" the interface . Yet to arrive chapter 5. I shall see what grinds up there. :roll: [ July 07, 2005: Message edited by: Akhil Trivedi ]