Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

A small doubt regarding Abstract classes...  RSS feed

 
Calvin
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi friends,

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:
"calvin"
[ July 31, 2006: Message edited by: Calvin ]
 
Campbell Ritchie
Marshal
Posts: 55681
162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch, Calvin.
Why can't an Abstract class extend an Interface . . . ?
But it can. As long as you spell "extends" i-m-p-l-e-m-e-n-t-s.


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."
 
Calvin
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ritchie !

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...

Hmmm...!
...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 ?!

Cheers,
"calvin"
 
Campbell Ritchie
Marshal
Posts: 55681
162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can only say "extends" one class, but you can "implement" several interfaces.
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."
 
Campbell Ritchie
Marshal
Posts: 55681
162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
something's gonna cause problems if THIS feature is ALLOWED..& hence they've BLOCKED it in the Language itself
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).

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.

CR
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Welcome to JavaRanch!

We have a strict policy on display names, which must be a real first and last name with a space between. One name isn't enough.

Please go here and fix your display name up, pronto. Thanks, pardner!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!