Computational Problem Solving with Java and Interactive Object Graphics

The DoodlePad Shape base class shares quite a bit of functionality with all its derived classes, including a wide array of pixel-perfect mouse events that each shape object may handle individually. But, what about the Shape class itself. What would happen if we attempted to instantiate Shape directly? How would it look?

An attempt to instantiate Shape will end with a compiler error, and that’s a good thing. After all, Shape is an abstract concept, not an actual graphic. It has no visual representation. The Shape class represents a generalized shape and it encapsulates the shared functionality of all concrete shape-derived classes in one place, to avoid the problems associated with code duplication. In fact, the Shape class was designed to be abstract. Never was there an intention that concrete Shape objects would be instantiated. This was part of the original design, and we’d like Java to help us enforce that design decision.

Fortunately, Java does give us the ability to prevent classes from being instantiated directly. This is accomplished by adding the appropriately-named abstract modifier to a class declaration. If you refer to the Shape class source code¹ you will see that Shape is declared with the abstract modifier.

/**
* Abstract base class for all graphical shape objects
* 
* @author Mark F. Russo, Ph.D.
* @version 1.1
*/
public abstract class Shape { ...

But modifying a class with abstract is not enough. If a class is abstract then it must also contain at least one method that is modified with abstract as well. A method with the additional abstract modifier is required to have no implementation. Instead, an abstract method is composed of a method signature only, and this signals that all derived classes must provide a concrete implementation of the method. Once again, the Java compiler enforces this design decision. Classes that extend an abstract base class must (eventually) provide a concrete implementation of all abstract methods.

If Shape is abstract, then it must have at least one abstract method declared. Of course it does. The one abstract method of Shape is draw(…), which should make some sense. The one unique feature of all Shape’s derived classes is their graphical representation. The draw(…) method is different for each derived class of Shape, and must be implemented. Modifying draw(…) with abstract in the Shape class enlists the compiler’s help to enforce the requirement that all derived classes must implement draw(…).

The complete definition of the SHape class’s draw(…) method is given in Listing 9.6.1. There is no method body! The definition is a signature only, no curly braces, just a semicolon (;). Shape can provide no implementation for draw(…) because it is abstract. But Shape methods depend upon there being a concrete implementation in each of its derived classes. This is guaranteed by the compiler through the addition of the abstract modifier.

/**
* Draw the shape. Abstract method to be overridden in derived classes.
* @param g The Graphics2D object on which to draw.
*/
public abstract void draw(Graphics2D g);    // Override in derived class

Abstract classes and abstract methods give us a way to express intended design constraints on our class definitions, which are checked and verified by the compiler. If a base class depends on its subclasses implementing certain methods that have no reasonable default implementation, then the base class is abstract. Modify the base class with the abstract modifier and include the abstract method signatures in the base class. The Java comiler will ensure concrete versions of these abstract methods are implemented in all derived classes so that all base class methods function properly.