Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Object-oriented language basics, Part 4

Inheritance: Build objects in layers

By Jeff Friesen, JavaWorld.com, 07/06/01

  • Print
  • Feedback

Page 2 of 10

Figure 4. A multilayered Circle object. (Reminds me of an onion. Onions, like ogres and objects, have layers.)

As Figure 4 shows, the multilayered Circle object contains three fields: x, y, and radius. However, Circle only declares radius; the other two fields are present in the internal Point layer. Subclasses are normally larger than superclasses because subclasses usually add fields and/or methods. For example, the Circle subclass adds a radius field and a getRadius() method.

A subclass can extend a superclass, provided the superclass has not been declared final. For example, if Point's declaration began with final class Point, the compiler would report an error. (For security reasons, you might want to prevent anyone from subclassing a class by declaring that class final.)

The inheritance syntax suggests that you can extend one and only one class. Java does not support multiple implementation inheritance. Java's designers take such a draconian stance against multiple implementation inheritance because it can lead to confusing problems. For example, suppose two base classes declare a nonconstant field with the same name but different types. Which field would the subclass inherit? The same idea holds with methods. If two methods with the same name but different parameter lists and/or return types appear in two base classes, which method does the subclass inherit? To prevent such problems, Java rejects multiple implementation inheritance. (Note: You can achieve the benefits of multiple inheritance by using interfaces.)

Calling superclass constructors

Examine Circle's constructor. Notice super (x, y);. It uses Java's super keyword to call the Point(double x, double y) superclass constructor and pass the contents of x and y as arguments to that constructor. It is important for Circle's constructor to call that Point constructor so that x and y properly initialize. Because Point declares those fields as private, no class apart from Point -- not even Circle -- can access them. To initialize x and y to values passed as arguments to Circle's constructor, Circle must delegate to Point's constructor by way of super (x, y);.

Suppose you modify Circle's constructor without super (x, y);, and then you try to compile the source code. What happens? The compiler reports an error. Here's why: A subclass constructor must always call a superclass constructor (unless a call to another constructor, via this, is present), whether or not source code explicitly specifies a constructor call. If you do not specify a constructor call (and this is not used to call another constructor), the compiler inserts code within a subclass constructor that calls its superclass default no-argument constructor. For example, if Circle's constructor lacked super (x, y);, the compiler would insert super (); to call Point(). Does Point have such a constructor? No, Point only has a Point(double x, double y) constructor. (The compiler only creates a default no-argument constructor for the class being compiled when no other constructor is present in that class.)

  • Print
  • Feedback

Resources