aspose file tools*
The moose likes Java in General and the fly likes Abstract Classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Abstract Classes" Watch "Abstract Classes" New topic
Author

Abstract Classes

Nilesh Srivastava
Ranch Hand

Joined: Aug 29, 2003
Posts: 70
Hi,

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

Also can we have constructors in abstract classes?

Regards,
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


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.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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!


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Adam Vinueza
Ranch Hand

Joined: Apr 16, 2001
Posts: 76
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.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
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.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
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

    Joined: Sep 29, 2002
    Posts: 1683
    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

    Joined: Aug 07, 2003
    Posts: 1646
    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

    Joined: Sep 29, 2002
    Posts: 1683
    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.
    Stuart Gray
    Ranch Hand

    Joined: Apr 21, 2005
    Posts: 410

    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

    Joined: Aug 07, 2003
    Posts: 1646
    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 ]
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Abstract Classes