2.1 Ballworld, inheritance-based  (Page 2/4)

Corresponding to the above notions, abstract classes in Java cannot be instantiated. Abstract classes are denoted by the abstract keyword in the class definition: public abstract class AFruit {...} By convention, the classnames of abstract classes always begin with "A".

In Ballworld, ABall is an abstract class representing a circular ball that has a number of properties: a color, a position, a velocity, etc. The abstract ball also has some defining behaviors, such as that all balls should paint a filled, colored circle when requested to display themselves on a graphics context (a panel). Likewise all balls know how to bounce off the walls of the container. These concrete behaviors are called "default behaviors" because all subclasses of ABall , such as StraightBall and CurveBall , automatically get these behaviors by default. One of the most common and useful reasons for using an abstract class is to be able to define the default behaviors for all the subclasses.

Abstract methods

But what about the abstract behaviors that abstract classes exhibit? For instance the abstract "ripening" behavior of a fruit? At the abstraction level of a fruit, the exact implentation of ripening cannot be specified because it varies from one concrete subclass to another. In Java, this is represented by using the keyword abstract as part of the signature of a method which has no code body: public abstract class AFruit { // rest of the codepublic abstract void ripen();} There is no code body because it cannot be specified at this abstraction level. All that the above code says is that the method does exist in all AFruit . The specific implmentation of method is left to the subclasses, where the method is declared identically except for the lack of the abstract keyword: public class Mango extends AFruit { // rest of codepublic void ripen() {// code to ripen a mango goes here }}public class Tomato extends AFruit { // rest of codepublic void ripend() {// code to ripen a tomato goes here }} The technical term for this process is called overriding . We say that the concrete methods in the subclasses override the abstract method in the superclass.

Note that if a class has an abstract method, the class itself must be declared abstract . This simply because the lack of code in the abstract method means that the class connot be instantiated, or perhaps more importantly, it says that in order for a class to represent abstract behavior, the class itsefl must represent an abstract notion.

Overriding is not limited to abstract methods. One can override any concrete method not declared with the final keyword. We will tend to avoid this technique however, as the changing of behavior as one changes abstraction levels leads to very unclear symantics of what the classes are actually doing.

In Ballworld we see the abstract method updateState . Abstract methods and classes are denoted in UML diagrams by italic lettering. This method is called by the update method as part of the invariant process of updating the condition of the ball every 50 milliseconds. The update method does 4 things:

1. Update the state of the ball by calling the abstract updateState method.
2. Move (translate) the position of the ball by adding the velocity to it.
3. Check if the ball needs to bound off a wall.
4. Paint the ball up on the screen.