• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Why cant a abstract class be instantiated?

 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi
i was this question by an interviewer today..my answer was the compiler wont allow it..and then i went to lengths explaining him the concept of abstract classes and how they implemented in derived class and only then you can have objects of that type..but still he kept asking me why??..give me a particular reason!!..is there any particular answer to it??
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I do agree that it's a bit of an odd question, like, "why can't a private method be accessed by another class?" Well, because it's private!!!
My answer, then, would simply be: because they're abstract. By declaring a class "abstract" you're saying that the class is incomplete and cannot be instantiated.
This becomes blatantly obvious in cases where you have declared methods in your class without method body, or where you implement interfaces but do not implement all the methods from those interfaces. But even when all interfaces are fully implemented and all methods have a body, an abstract class remains, erm, well, abstract.
- Peter
 
Ranch Hand
Posts: 263
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
but you can . try super() in the constructor. means the parent is instantiated, which is an Abstract class.
 
Bartender
Posts: 1844
Eclipse IDE Ruby Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Think of it this way:
If you had a class Vertebratum (things with backbones), does it make sense to instantiate that class? No, of course not. You have to instantiate some subclass, like PurpleTailedSparrowhawk or Goldfish.
An abstract class be definition is not a complete class; some parts are missing that have to be filled in by the subclass.
An abstract class is never instantiated. Calling super() calls the code in the parent, but that is still part of the instance of the subclass.
 
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
but you can . try super() in the constructor. means the parent is instantiated, which is an Abstract class.
I'm not touchin' this one with a ten-foot pole! No more philosophical discussions in Cindy's forum!
 
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michael Morris:
I'm not touchin' this one with a ten-foot pole! No more philosophical discussions in Cindy's forum!


Now, Michael! Let's not be hasty. Nothing wrong with a little philosohpy now and then. You just have to be patient with me when I chuckle at you . Course nothing prevents YOU from plain old laughing out loud at ME .
Besides . . . now I am interested in what you have to say. Come on into my [strikeout]lair[/strikeout] sitting room and let me hear what you have to say. .
[ April 29, 2003: Message edited by: Cindy Glass ]
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[aadhi]: but you can . try super() in the constructor. means the parent is instantiated, which is an Abstract class.
[Michael]: I'm not touchin' this one with a ten-foot pole! No more philosophical discussions in Cindy's forum!

Well, I'll bite - I'm still young and foolhardy.
It is misleading (and/or flat-out wrong) to say that calling the super() constructor "instantiates" a superclas object. This makes it sound like when child constructor is completed, there's a little superclass object inside a child class object. This is not the case - there's just one object created, and its class is the child class type. In one sense any child class instance "is an" instance of the superclass as well - but it's never just an instance of the base class. Consider:

This gives output

Clearly, the instance being created is a Child, not a Parent - even while the Parent constructor is running. It's misleading to say you've "instantiated" a Parent wit the super() constructor. You're still in the process of instantiating a Child.
Maybe aadhi knows this, and it's not what he/she meant - but I've seen enough people who were confused on this point that I'd prefer not to see it spread through careless use of language. So no, you can't instantiate an abstract class, period.
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
but still he kept asking me why??..give me a particular reason!!..
I think the interviewer was trying to test your understanding of the concept, rather than the knowledge of Java syntax.
Abstract classes are purposefully incomplete, -- they are just the structure, the framework, the base of some hierarchy. You can't instantiate them for the same reason that you can't instantiate interfaces, -- they are not really entities that can be alive. Instead, they are just the descriptors, meaningfull only when applied to real objects.
Eugene.
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


So no, you can't instantiate an abstract class, period.


Ok, you and Cindy both twisted my arm. From a semantic point of view I totally agree with that statement. But from a structural point of view a super is always created. Just disassemble the code for the abstract super class and for the subclass. This was my basic argument over private inheritance. Stucturally subclasses do not inherit private state but semantically they do. As OO progrmmers we should always think in the abstract (semantically) not in the concrete (structurally).
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, we're basically in agreement here, but you see my view here as inconsistent with my view on inheritance of private members? OK. From my perspective, I just used the JLS definition in both cases. I didn't explain it in JLS terms for this second case, since what you call a "semantic" argument seemed simpler - but in this case both interpretations (JLS and "semantic") were in agreement. If they hadn't been, I probably would've gone with whatever the JLS said for consistency, but also acknowledged the alternate interpretation.
 
aadhi agathi
Ranch Hand
Posts: 263
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jim Yingst:

It is misleading (and/or flat-out wrong) to say that calling the super() constructor "instantiates" a superclass object. This makes it sound like when child constructor is completed, there's a little superclass object inside a child class object. This is not the case - there's just one object created, and its class is the child class type. In one sense any child class instance "is an" instance of the superclass as well - but it's never


Ok accepted. then how would we prove the following code which calls a [b]private method

not in the scope of the child.ie. this.getClass() is Child and this.getClass().getDeclaredMethods() doesn't have any glimpse of the private method. Still it calls the method. So "this" lies or behaves differnly when comes to the private method. can you please explain it to me.


Clearly, the instance being created is a Child, not a Parent - even while the Parent constructor is running. It's misleading to say you've "instantiated" a Parent wit the super() constructor. You're still in the process of instantiating a Child.


considering the above example, is it not proper to say "this" holds the visibilty and access rights only to the scope of the exact Class where "this" is employed


Maybe aadhi knows this, and it's not what he/she meant - but I've seen enough people who were confused on this point that I'd prefer not to see it spread through careless use of language.


Is it not a general principle (Heuristic Principle i guess) to assume that the Parent shoudl't be aware of the child. Meaning "this" should be "treated" to hold the visibilty and access rights only to the scope of the exact Class where "this" is employed
if i say this.getClass() in Parent and try doing something not related to Parent's access or visibility , then IMHO, i do something very very
nasty. we loss the abstraction , scope, visibilty and every good OOAD principle . but your example is exciting though

Let us see where it leeds to... happy to hear your thoughts.
 
aadhi agathi
Ranch Hand
Posts: 263
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michael Morris:

From a semantic point of view I totally agree with that statement. But from a structural point of view a super is always created.


i like your "semantic" usage, but it confues me like the "sematic usage" in UML spec UML_spec_1_5. can you explain what is "sematic" . i guess it is the "general rule", but who frames it for inheritance ???


from UML 1.5 spec, section 2-69, page 127 in pdf version
In a pre-object-oriented language, the full descriptor of a data structure
was declared directly in its entirety. In an object-oriented language, the description of
an object is built out of incremental segments that are combined using inheritance to
produce a full descriptor for an object.


This "combined" is composition interanlly is my humble assumption.


Just disassemble the code for the abstract super class and for the subclass. This was my basic argument over private inheritance. Stucturally subclasses do not inherit private state but semantically they do. As OO progrmmers we should always think in the abstract (semantically) not in the concrete (structurally).


But private inheritance is not supported semantically(rules??) too. if it supports private inheritance then the semantic is defined absolutely wrong
 
aadhi agathi
Ranch Hand
Posts: 263
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michael Morris:
I'm not touchin' this one with a ten-foot pole! No more philosophical discussions in Cindy's forum!


the damage is already done !!
 
reply
    Bookmark Topic Watch Topic
  • New Topic