• 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

Abstract Classes

 
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Can we instantiate an ABSTRACT CLASS. I believe the answer is NO. But why?

Also can we have constructors in abstract classes?

Regards,
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Can we instantiate an ABSTRACT CLASS


No. Why? Well, because it's abstract. Simple as that.


Also can we have constructors in abstract classes?


Yes (as you could have found out if you had created on to see). Consider abstract classes a kind of templates to developers creating subclasses. They do more than an interface (which only defines the methods a class must implement) they also suggest how such methods should be implemented.

Suppose I wanted to create a class which validates an object of the type String. Does it make any sense to allow such validation classes to exists without a String to validate? No. But does it make sense to allow different validation rules for this class? Yes. So I could define this abstract class:

Now, all classes which extends this must supply a constructor which takes a String, and implement a validate method.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The whole point of the abstract keyword on a class is to say you can't instantiate it, so instead of "Why can't you instantiate an abstract class?" let's ask "Why would anybody want to make a class you can't instantiate?" The most common reason is that the class is a partial implementation but is not complete enough to be useful on its own. Abstract classes often have some base behavior that all subclasses will need and some methods that the subclasses must fill in for themselves. The abstract keyword on a method requires the subclass to override the method (or to be another abstract class.)

We see this a lot in frameworks. They provide some basic functionality and have abstract methods where you can (or must) provide customized code.

Man, I'm coming up blank on simple examples right now. Maybe somebody else will pitch in. Hope that helps!
 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A stock example from OO courses is a Shape class in an application that makes use of geometric shapes. A Shape class would probably have various useful functions, such as draw(), area(), perimeter(), and so on. The Shape class is made to be extended, as the draw(), area(), and perimeter() functions might be very different depending on what kind of Shape we're talking about. Moreover, there seems to be no point to implementing draw(), area(), and perimeter() functions for a Shape that isn't also a Rectangle or Circle or some other specific Shape; users will work with those things, not with Shapes as such. This means there would seem to be no point to making a Shape object, so we might as well make Shape abstract.

In general, when you've got some number of classes that have common data members and superficially similar behavior, but no common underlying behavior, it's appropriate to create an abstract class and have these classes extend it. By contrast, if the classes don't have common data members, it's appropriate to have them implement a common interface.
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Can we instantiate an ABSTRACT CLASS. I believe the answer is NO. But why?

Also can we have constructors in abstract classes?


Although you (the programmer) cannot instantiate an abstract class, such a class will be instantiated when:

1. Its subclass is instantiated

and

2. The abstract class has a non-private contructor.

When the abstract class is instantiated, its instance variables will be initialized.
 
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Roger Chung-Wee:
Although you (the programmer) cannot instantiate an abstract class, such a class will be instantiated when . . .

While I'm not the best person to argue semantics in this area, I would say that while the abstract class's instance fields are initialized and its constructor is called, it's not being instantiated.

Instantiating a class means that you are creating an object with that class as its type. Instantiating a class that extends an abstract class doesn't create an object with the abstract class as its type since every object has one and only one type.

Don't confuse this with the fact that the object will satisfy the "instanceof" operator since it's satisfied whenever the object's type
  • is the class being tested,
  • is a decendent of the class being tested, or
  • implements the interface being tested.
  • Just to be clear, I'm not trying to nitpick. I just want to make sure we don't confuse anyone or make someone say, "of course abstract classes can be instantiated," in an interview.
     
    Roger Chung-Wee
    Ranch Hand
    Posts: 1683
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The abstract class has to be instantiated, otherwise its instance variables cannot be inherited by the subsclass. This would result in an incomplete subclass object being created.

    When a non-abstract class is instantiated, all other classes up its hierarchy must also be instantiated. If this were not so, then some objects would not inherit the methods of the Object class. It would be undesirable to discover that some objects have no equals() method ...
     
    David Harkness
    Ranch Hand
    Posts: 1646
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Roger Chung-Wee:
    The abstract class has to be instantiated, otherwise its instance variables cannot be inherited by the subsclass. This would result in an incomplete subclass object being created.

    I understand what you mean, but I'm making the semantic argument that this is called initializing the superclass. The distinction is that when you use the new operator or its equivalents, you are instantiating a single object that has a single class type, whereas each class in the type's chain of ancestors is responsible for initializing a portion of the object's state.

    I think the last paragraph of section 15.9 of the JLS 2nd edition agrees with my interpretation.

    We say that a class is instantiated when an instance of the class is created by a class instance creation expression. Class instantiation involves determining what class is to be instantiated, what the enclosing instances (if any) of the newly created instance are, what constructor should be invoked to create the new instance and what arguments should be passed to that constructor.

    Since each object is a single instance of a class, and a single object is created (ignoring any created by field and instance initializers or constructors) for a single instance creation expression, it follows that only one class is instantiated.

    Reading further, section 15.9.4 is more explicit. It continually makes reference to a single class instance being created. If each superclass was being instantiated as well, multiple class instances would be created.
     
    Roger Chung-Wee
    Ranch Hand
    Posts: 1683
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Well, let's check to see what the Java bible has to say about abstract class instantiation:

    A subclass of an abstract class that is not itself abstract may be instantiated, resulting in the execution of a constructor for the abstract class and, therefore, the execution of the field initializers for instance variables of that class.


    So, as far as I am concerned, when the abstract class's constructor is executed, then that class is instantiated and (as the JLS says) its fields are therefore initialized.
     
    Ranch Hand
    Posts: 410
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator


    Now, all classes which extends this must supply a constructor which takes a String, and implement a validate method.


    This isn't strictly true. All classes which extend must make a call to one of the superclass' constructors. So the following class compiles even though it doesn't implement a constructor with a String arg:

    But if we removed the call to super, it would fail to compile because there would be an implicit call to the super constructor with no arguments (which is not accessible).
     
    David Harkness
    Ranch Hand
    Posts: 1646
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Roger Chung-Wee:
    So, as far as I am concerned, when the abstract class's constructor is executed, then that class is instantiated and (as the JLS says) its fields are therefore initialized.

    I agree that the abstract class's constructor is called, and its fields are initialized, but these actions do not define instantiation. Rather, they are a subset of the actions that make up instantiation. The paragraph immediately preceding the one you quoted is quite explicit.

    From JLS 8.1.1.1 in reference to an example:

    The class Point cannot be instantiated because it is abstract.

    If calling a class's constructor and initializing its fields meant that the class had been instantiated, then the quote above would be incorrect and the part you quoted should have read

    A subclass of an abstract class that is not itself abstract may be instantiated, resulting in the instantiation of the abstract class. (my emphasis)

    I think that's about all I can say about it. I'm happy to agree to disagree, especially when it's about semantics. We're in agreement on what actions the JVM actually takes, and that's the important part.
    [ April 30, 2005: Message edited by: David Harkness ]
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic