Why can't an Abstract class extend an Interface (which is like a purely Abstract class...)
Esp., why can't i have code like the following ??
NOW, i Do know that allowing that will cause some problems...but i jus' needed your thoughts/ideas on this...
Thanks a lot in advance...! :roll:
[ July 31, 2006: Message edited by: Calvin ]
But it can. As long as you spell "extends" i-m-p-l-e-m-e-n-t-s.
Why can't an Abstract class extend an Interface . . . ?
Your example would be entirely acceptable Java as long as you change "extends" to "implements."
The reason for the keywords is that a superclass provides some functionality, and the subclass makes that functionality more, or "extends" the functionality.
If you have a "purely-abstract" class, it has no functionality, but it does present an interface, to the other classes. An interface means the list of public methods, with their signatures and return types. That is why they chose to call it "interface." But it has no functionality; all its methods are unimplemented. So whoever uses the interface has to implement all its methods, hence the use of the keyword "implements."
An interface means the list of public methods, with their signatures and return types. That is why they chose to call it "interface." But it has no functionality; all its methods are unimplemented. So whoever uses the interface has to implement all its methods, hence the use of the keyword "implements."[/QB]
Yeah, i do know about the implements Key-word, which says that my class will try n "fulfill" the Contract of the INTERFACE...
Well, but an Abstract class too may or may NOT provide any functionality at all...
i was wondering as to WHY not ALLOW a class to EXTEND an INTERFACE...thereby "inheriting" its CONTRACT ( list of methods, which are by default, public abstract )...
...BUT, since, i EXTENDED & Not IMPLEMENTED the Interface...i Did NOT "Fulfil" the INTERFACE...So, i should mark my CLASS as ABSTRACT...so that, ANY CONCRETE class "down the family-tree" WILL have to implement the abstract methods in my ABSTRACT class, as well as the INTERFACE...
...I don't see anything wrong in my chain of reasoning...except for something subtle in the JLS itself...may be, something's gonna cause problems if THIS feature is ALLOWED..& hence they've BLOCKED it in the Language itself ?!?
Me still thinking on it..!
Please Lemme know if you hit upon anthing in this regard...ok ?!
And as you say, if you have an abstract class implementing an interface, you are still allowed to leave some of the interface's methods empty.
As you have implied, there is a "spectrum" of different types of entities analagous to classes:-
Interface->to be implemented, differently every time.
Abstract class->to be implemented, differently in part.
Concrete class->already implemented, but can be extended with changes.
Final concrete class->already implemented, no extension or changes permitted.
Enumerated type->fully implemented, list of objets with their values set. No changes. Imagine it is "read only."
Exactly. The C++ language which Java was derived from, allows multiple inheritance. C# which is derived from C++ too, (and I suspect with influence from Java) does not allow multiple inheritance (if I remember correctly).
something's gonna cause problems if THIS feature is ALLOWED..& hence they've BLOCKED it in the Language itself
Yes, it was because Gosling removed what he considered confusing features (multiple inheritance, operator overloading) when originally designing Java. There were some useful features (eg assertions, generics) which were also omitted from earlier versions, and only reintroduced in J1.4 or J5 unfortunately. Got to go now. Lots to do.
When it is used for evil, then watch out! When it is used for good, then things are much nicer. Like this tiny ad:
The WEB SERVICES and JAX-RS Coursehttps://coderanch.com/t/690789/WEB-SERVICES-JAX-RS